What makes requirements excellent. How a developer can work with requirements. Babok introduction
Each developer works with requirements constantly. Below we will share detailed information of what is a requirement, how to create excellent requirement, requirements level, and benefits from good requirements. This material is not for BA, it is a short introduction for developers and delivery, short BaBok quiz.
The article is a summary and quotes of the book.
Requirement definition
Requirement is formulated necessity
The BABOK defines standard requirement as a condition or capability needed by a stakeholder to solve a problem or achieve an objective.
Levels of Requirements
On each step of your work, you need to understand the reasons for some requirements occurrences. If you understand business requirement it is much easier to create optimal solution requirements.
Business requirements are the highest level of requirements and are developed during Enterprise Analysis activities. They define the high-level goals, objectives, and needs of the organization. Business requirements are progressively elaborated into the next level of detail, the stakeholder requirements.
Stakeholder requirements define the needs of stakeholders and how they will interact with a solution. Stakeholder requirements bridge between the high-level business requirements and the more detailed solution requirements.
Solution requirements describe the solution characteristics that will be needed to meet the higher-level business and stakeholder requirements. Solution requirements are subdivided into three types: functional, non-functional and transition requirements.
Functional requirements define the capabilities that a product must provide to its users while non-functional requirements describe quality attributes, design and implementation constraints and external interfaces that the product must-have.
Transition requirements define the solution capabilities required to transition from the current to the future state and are no longer needed once the transition is complete.
Non-functional requirements
Requirements are often missed during communication. It is great to have some check-list before communication session starts
Characteristics of Excellent Requirements
Good requirements should be:
- Unambiguous
- Testable (verifiable)
- Clear (concise, terse, simple, precise)
- Correct
- Understandable
- Feasible (realistic, possible)
- Independent
- Atomic
- Necessary
- Implementation-free (abstract)
Unambiguous
REQ1 The system shall not accept passwords longer than 15 characters.
It is not clear what the system is supposed to do:
- The system shall not let the user enter more than 15 characters.
- The system shall truncate the entered string to 15 characters.
- The system shall display an error message if the user enters more than 15 characters.
The corrected requirement reflects the clarification:
REQ1 The system shall not accept passwords longer than 15 characters. If the user enters more than 15 characters while choosing the password, an error message shall ask the user to correct it.
Testable (Verifiable)
Some words can make a requirement untestable:
Some adjectives: robust, safe, accurate, effective, efficient, expandable, flexible, maintainable, reliable, user-friendly, adequate
Some adverbs and adverbial phrases: quickly, safely, in a timely manner
Nonspecific words or acronyms: etc., and/or, TBD
Clear
REQ1 Sometimes the user will enter Airport Code, which the system will understand, but sometimes the closest city may replace it, so the user does not need to know what the airport code is, and it will still be understood by the system.
This sentence may be replaced by a simpler one:
REQ1 The system shall identify the airport based on either an Airport Code or a City Name.
Correct
If a requirement contains facts, these facts should be true:
REQ1 Car rental prices shall show all applicable taxes (including 6% state tax).
The tax depends on the state, so the provided 6% figure is incorrect.
Independent
To understand the requirement, there should not be a need to know any other requirement:
REQ1 The list of available flights shall include flight numbers, departure time, and arrival time for every leg of a flight.
REQ2 It should be sorted by price.
The word “It” in the second sentence refers to the previous requirement. However, if the order of the requirements changes, this requirement will not be understandable.
Feasible (Realistic, Possible)
REQ1 The system shall have a natural language interface that will understand commands given in English language.
This requirement may be not feasible within a short span of development time.
Atomic
The requirement should contain a single traceable element:
REQ1 The system shall provide the opportunity to book the flight, purchase a ticket, reserve a hotel room, reserve a car, and provide information about attractions.
This requirement combines five atomic requirements, which makes traceability very difficult. Sentences including the words “and” or “but” should be reviewed to see if they can be broken into atomic requirements.
Necessary
A requirement is unnecessary if
None of the stakeholders needs the requirement.
or
Removing the requirement will not affect the system.
Consistent
There should not be any conflicts between the requirements:
REQ1 Dates shall be displayed in the mm/dd/yyyy format.
REQ2 Dates shall be displayed in the dd/mm/yyyy format.
This can eventually lead to the following requirement:
REQ3 Dates shall be displayed based on the format defined in the user’s web browser.
Nonredundant
Each requirement should be expressed only once and should not overlap with another requirement:
REQ1 A calendar shall be available to help with entering the flight date.
REQ2 The system shall display a pop-up calendar when entering any date.
Implementation-free (Abstract)
Requirements should not contain unnecessary design and implementation information:
REQ1 Content information shall be stored in a text file.
How the information is stored is transparent to the user and should be the designer’s or architect’s decision.
Complete
A requirement should be specified for all conditions that can occur:
REQ1 A destination country does not need to be displayed for flights within the U.S.
REQ2 For overseas flights, the system shall display a destination country.
What about flights to Canada and Mexico? They are neither “within the U.S.” nor“overseas.”
Benefits from a High-Quality Requirements Process
- Fewer defects in the delivered product
- Less development rework
- Faster delivery of the finished product
- Less unused features
- Lower cost of development
- Less miss-communicated requirements
- Reduced project chaos
- Higher levels of satisfaction from stakeholders
- Higher levels of satisfaction from developers
- Higher levels of satisfaction from consumers and users
- Products that work well and have a useful feature set
Conclusion
Hope this short introduction makes a bit clearer understanding of what requirements are, how to create them and how they impact the project.
Material is prepared based on BaBook review.
Written by Dolgaryeva Anastasiia
Proofread by Mariana Vechirko
