What makes a good requirements specification

All Users. Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here. Quality Description See also Atomic A requirement should articulate a single stakeholder need or a quality attribute.

Attainable The need specified in the requirement must be achievable. Cohesive The requirements as a set must be consistent and cohesive and express the behavior of the system; any gaps must be determined and overlap between requirements must be resolved.

Relationship Matrix Complete Each requirement must fully describe the necessary functionality or behavior that will result in the stakeholder's need being met. Current A Requirement must be up-to-date and reflect the current knowledge and project status.

Independent The requirements should be independent of each other, and not have overlapping statements that conflict with each other or restate the same need. Modifiable This means that a requirement can be changed without there being the need to modify other related requirements.

Traceable A Requirement is a specification of a characteristic or behavior, and does not exist in isolation but is typically related to up-process entities such as stakeholders, business drivers and goals, and down-process entities such as Use Cases and components. Unambiguous A requirement should only be able to be interpreted in one way. Verifiable A requirement is verifiable if the implemented system or product can be tested to ascertain that the requirement has been met. Necessary Requirements should record a capability or behavior that is really needed or that specifies that the system or product should comply with constraints such as standards.

Feasible A requirement that cannot be implemented will mean that the need of the stakeholder will not be met. Prev Next. Resources Resources UML 2. All rights Reserved. It must contain all the information necessary for the developer to design and implement that bit of functionality. Resolve all TBDs in each portion of the requirements before you proceed with construction of that portion.

Nothing says you need to make the entire requirements set complete before construction begins. However, projects using iterative or incremental development life cycles should have a complete set of requirements for each iteration.

Using minimal requirements specifications runs the risk of having different people fill in the blanks in different ways, based on different assumptions and decisions. Keep requirements details verbal instead of written also makes it hard for business analysts, developers, and testers to share a common understanding of the requirements set.

The reference for correctness is the source of the requirement, such as an actual user or a high-level system requirement. A software requirement that conflicts with its parent system requirement is not correct. Only user representatives can determine the correctness of user requirements such as use cases , which is why users or their close surrogates must review the requirements.

It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment. To avoid specifying unattainable requirements, have a developer work with marketing or the BA throughout the elicitation process. The developer can provide a reality check on what can and cannot be done technically and what can be done only at excessive cost.

Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility. Every requirement should originate from a source that has the authority to specify requirements. Trace each requirement back to specific voice-of-the-customer input, such as a use case, a business rule, or some other origin of value.

Assign an implementation priority to each functional requirement, feature, use case, or user story to indicate how essential it is to a particular product release. Prioritization is an essential key to successful iterative development. All readers of a requirement statement should arrive at a single, consistent interpretation of it, but natural language is highly prone to ambiguity. Sometimes it is possible to resolve the conflict by analyzing the conditions under which the requirement takes place.

In this case the conflict cannot be resolved by adding conditions, so one of the requirements should be changed or removed. Indirect conflict occurs when requirements do not describe the same functionality, but it is not possible to fulfill both requirements at the same time:.

REQ1 For outbound and inbound flights, the user shall be able to compare flight prices from other, nearby airports. REQ2 The outbound and return flights shall be sorted by the smallest number of stops. The usage should be consistent. The first requirement related to only the flight date is a subset of the second one related to any date entered by the user.

REQ1 A destination country does not need to be displayed for flights within the U. What about flights to Canada and Mexico? All applicable requirements should be specified. This is the toughest condition to be checked. A good requirement should have more criteria. However, they usually can be expressed as a combination of the criteria we have just discussed:. I would like to receive exclusive offers and hear about products from InformIT and its family of brands.

I can unsubscribe at any time. Pearson Education, Inc. This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:.

For inquiries and questions, we collect the inquiry or question, together with name, contact details email address, phone number and mailing address and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information informit. On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Do not speculate; avoid drawing up wish lists of features that are impossible to achieve. Avoid duplication and contradictory statements.

Do not express suggestions or possibilities. You can identify these wherever you see statements with might, may, could, ought, etc. Avoid creating a jigsaw puzzle where requirements are distributed across documents, causing you to cross-reference documents.

This can make your RSD extremely difficult to read. Do not refer to a requirement that is yet to be defined. Again, your objective is to make the document as much of an easy read as you can. Do you have any more to add to this list? Don't forget to leave a comment below.