Characteristics of Good Requirements

More often than not errors and deficiencies in systems can be traced back to requirements engineering, and the literature frequently mentions the small cost of correcting a requirement compared to the large cost of correcting the system once it is built. Well articulated, managed and tested Requirements are therefore imperative to any system development process. Enterprise Architect has a convenient Requirements Checklist element available from the 'Extended Requirements' page of the Requirements Toolbox.

The Checklist can be used to indicate if a Requirement is ready for implementation.

Qualities of Good Requirements

To be effective a set of Requirements must be complete and fully record the stakeholders' needs consistently, cohesively and unambiguously. Enterprise Architect provides an extensive set of features and tools for helping the analyst produce sets of Requirements that are of high quality.

Quality	Description	See also
Atomic	A requirement should articulate a single stakeholder need or a quality attribute. When a requirement contains multiple needs it is not possible to analyze the needs independently. Enterprise Architect can assist by allowing modelers to create hierarchies of requirements in the Project Browser, which can be broken down to an atomic requirement.
Attainable	The need specified in the requirement must be achievable. If a requirement is not attainable the system will not be able to deliver the business value required by the stakeholders. Enterprise Architect can assist by allowing each requirement to be traced to an implementation element such as a Use Case or a Component. The Relationship Matrix can be used to quickly identify those requirements that are not traced to a lower level element.
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. Following a requirements process will assist greatly and Enterprise Architect has a number of facilities that will make it easy to keep the requirements cohesive. Missing requirements can be identified using the Relationship Matrix where for example a matrix between stakeholders and their requirements would quickly identify stakeholders who didn't have requirements.	Relationship Matrix
Complete	Each requirement must fully describe the necessary functionality or behavior that will result in the stakeholder's need being met. Enterprise Architect can help by team members using the Team Library facility or the Collaborate window. Some analysts like to mark requirements as needing to be completed by appending the requirement with a tag such as 'TBC'. Enterprise Architect can assist by allowing the analyst to search across the requirements Packages for this tag and return a list of elements that require further work. A Model View could also be set up using this search to populate the view. The Collaborate window is also helpful because the information added is not part of the requirement itself and does not contaminate the requirement's notes with text that isn't part of the Requirements definition.
Current	A Requirement must be up-to-date and reflect the current knowledge and project status. Enterprise Architect can assist the analyst by allowing the sources of requirements to be modeled and the requirements themselves can be traced back to these artifacts so when the source is changed all the affected elements could be located.
Independent	The requirements should be independent of each other, and not have overlapping statements that conflict with each other or restate the same need. A degree of analysis will be required as there will inevitably be some overlap, but this can be kept to a minimum by creating requirements in hierarchies and working systematically. Enterprise Architect has a number of features that can assist with this, including the Relationship Matrix, which will help to identify overlap. The powerful and flexible search function could also be used to identify overlapping or conflicting statements.
Modifiable	This means that a requirement can be changed without there being the need to modify other related requirements. It also applies to a Software (System) Requirements Specification and requires that it can be changed easily. Enterprise Architect can assist with both these issues; the Requirements themselves can easily be located through the search facility, and the text and properties changed easily. The System Requirements Specification is automatically generated from the model, so by simply changing one or more requirements and regenerating the document it will be updated.
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. Enterprise Architect allows elements to be traced in any direction and provides a number of powerful tools to visualize the traces, including the Relationship Matrix, the Traceability Window and the Requirements diagram itself. The Insert Related Elements facility can be used to automatically construct a diagram of traces.
Unambiguous	A requirement should only be able to be interpreted in one way. Requirements that are ambiguous can lead to a project being delayed, over budget or having the wrong functionality or behavior. Enterprise Architect can assist with ambiguity by helping analysts to record comments about the requirements, using the Element Discussion facility.
Verifiable	A requirement is verifiable if the implemented system or product can be tested to ascertain that the requirement has been met. Key to being able to achieve this is knowing which test must be run to verify a particular requirement. Enterprise Architect can assist by allowing the modeler to trace Test Cases back to requirements and to visualize their relationship in a number of ways, including the use of the Relationship Matrix. Test results can also be recorded directly inside Enterprise Architect.
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. Enterprise Architect can assist by allowing the modeler to relate each requirement back to its source and using the Relationship Matrix; requirements that have no source will be obviously identified as unnecessary or needing further investigation.
Feasible	A requirement that cannot be implemented will mean that the need of the stakeholder will not be met. It is best to identify these requirements as quickly as possible so as not to disappoint the owner of the requirement. Enterprise Architect can assist by allowing analysts, architects, designers and developers to discuss the requirement and determine its feasibility using the Collaborate window.