REQUIREMENTS ON REQUIREMENTS

How hard could it be? A healthy way of analyzing and documenting requirements at front could spare you some headache and even help your development, verification and validation processes.

The requirements shall be:

• Clear and Feasible (can be met with a solution that is possible in terms of cost, schedule and technical constraints and are sufficient to specify the system without being unnecessarily numerous or detailed)
• Independent of implementation
• Traceable
• Verifiable
• Consistent and Complete (Revels everything that is relevant to the system or system element and are not contradictory or duplicated and use the same terminology)
• Prioritized

They could be defined as a “Must” or “Should” requirements. It is good to avoid superlatives as best, user-friendly, fastest; vague pronouns like that, he, she; unclear adverbs and adjectives like real-time, almost, always, many.

Examples of requirement statements of different quality:

• Bad example: (not complete and verifiable): The system should have 99.9% availability
• Good example: During 7 days of continuous operation, the system may be inaccessible for a maximum of 300 seconds
• Less good: The system should be user friendly. How can this be verified?
• Good: The user interface should have help texts. Clear and verifiable and provides better usability
• Bad example: (inconsistent): The chassis should be black, the box should weigh a maximum of 15 kg
• Good example: The chassis should be black, the chassis should weigh a maximum of 15 kg

Good practices when writing requirements:

• Use a convention to distinguish mandatory requirements from non-mandatory ones
• Use the same grammatical building blocks to express similar requirements
• Use a glossary to define a way of expressing yourself in different requirements
• Use of acronyms should always be explained. Have a list with all acronyms
• Use a list of abbreviations that are included in the requirement specification
• Use a project-wide template
• Do not mix terminology in different requirements;  for example, the computer, the system when you mean the same thing

Relations between requirements

It is important to group related requirements to each other, link each requirement to the requirement on which it depends and the ones that help satisfy it. Each requirement must be linked to the test artifacts that assist its verification.

Requirement relationships should be traceable from the highest to the lowest level. Clarify the requirements from higher level so as not to introduce risk at lower level.

Explain and give examples of which relations are in the requirements context and how those are used in the processes of going from customer requirements to system ones.

Traceability of the requirements is about being able to derive development and functions in the system to the actual needs of the stakeholder. It is also used to clarify the requirements and possible limitations, document and ensure that all higher level requirements are met, allocate them to subsystem or system elements and measure progress in the requirements process (% from highest level allocated/tracked).

Working further with requirements

Once all the requirements have been identified, document, grouped and linked the work can continue breaking down them into the different parts of the system to be built, allocating them to system elements.

By dividing systems into elements, you can break out independent elements that can be handled separately. On the one hand, it can lead to modules that can be reused in several projects.

Traceability is not an end goal in and of itself but, rather, a tool that can be used to help allocating requirements further. It also will help:

• Improve the integrity and accuracy of all requirements, from the system level all the way down to the lowest configured item
• Allow tracking of the requirements development and allocation and generating overall measures
• Support easier maintenance and change implementation of the system in the future

And the following benefits will be obtained out of the work with traceability of requirements:

• Could define the functionality of a given system element
• Better understanding of whether certain requirements are applicable to several different system elements
• Help the system design, dictates how it should be designed

In practice the requirements often are handle using tool such as DOORS or Enterprise Architect there all the requirements are documented and then tracked to different artifacts.

Customer will say: I know it when I see it. Find appropriate level of abstraction from the beginning, starting with requirements, and reduce complexity so you don’t end out in a chaos situation.