This part covers the definition of requirements.
Requirement Definition:
According to the “Guide to the Business Analysis Body of Knowledge” requirement is:
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).
The definition is based on IEEE 610.12-1990
For me, requirements are a list of things that agreed by stakeholders what a product must be (form, fit function) by the time it’s released to be sold. It is all about setting expectations with stakeholders (business, technical) that the product we release fits our specific market.
Why Do Projects Fail?
The most common reasons for project failures are not technical. The table below identifies the main reasons why projects fail. The most common problem falls under incomplete requirements (unorganized, fuzzy or unrealistic).
Incomplete requirements 13.1%
Lack of user involvement 12.4%
Lack of resources 10.6%
Unrealistic expectations 9.9%
Lack of executive support 9.3%
Changing reqs/specs 8.7%
Lack of planning 8.1%
Didn’t need it any longer 7.5%
* Source for this table: Standish group 1995& 1996 from the book “Requirements Engineering” by By Elizabeth Hull, Ken Jackson, Jeremy Dick
Main Requirements Types:
Product Design- The product design includes any direction for the design of the product. I usually include a couple of pages describing the product design, users, restrictions, the do and don’t. Example: “A user shall not require any training to use the product. This means the user will know how to use it the first time the user tries it. The out of the box experience need to educate users and provide clear direction on use.
General requirements- the general requirements state the required qualities that are not a design requirement such as business requirements. Example: The number of stocking items shall be limited to 4 days or 200 units. The Cost of Goods Sold (CoGS) shall be $1250 USD or less.
Physical requirements- the physical requirements state the required physical characteristics of the product such as dimensions and mass. Example: The weight of the unit shall be 30 kilograms or less.
Resource requirements- the resource requirements state the constraints such as external limitations of the developed unit. Example (electrical power): The power supply input voltage range shall be 90Vrms to 200Vrms.
Environmental requirements- the environmental requirements state the external physical environment the developed product will be used ambient temperature, humidity, radiation, shock, vibration, wind speed, dust, etc. Example: The equipment shall survive, in a non-operating state and with no subsequent loss of functionality, exposure to the standard humidity environment, with the test methods specified in xxx (spec), Section xxx (section).
Connector requirements- the requirements of the connector state the external interface of the developed product including how those labeled. Examples: 1. The connectors shall be separated by, or have a clearance of, at least 1.00 inch. 2. The equipment shall be designed so that plugs can only be inserted into the correct receptacle.
Performance requirements- the performance requirements state how well (latency, speed, responsiveness) the product will be performed by functionalities.
Functional requirements- The functional requirements state what the product is to do on normal and abnormal operations. Example: The unit shall be capable of switch direction upon a request message by the controller.
State requirements– the state requirements state the required states and modes of the product. It is recommended adding a diagram describing states, modes, and timing. Example: The unit shall have three power states: on, standby, and off.
Other Potential Requirements:
Regulatory, Reliability, Efficiency, Usability, Packaging and Survivability, Maintainability, Manufacturability, Transportability, Reusability, Security, Interchangeability, Marking, Personnel Hazard, Electromagnetic Compatibility, Electrical, and Electronic Requirements, Software Processes and Development Standards, Materials, etc.
Writing A Quality Requirement:
I have seen good requirement documents and some great requirements documents. What made the difference was the expertise of the originator (system engineer, project engineer). The success of the project and the developed product is based on the quality of this document.
Most requirements follow this template: The “thing” shall “provide” this to achieve “this”. Example: The Cost of Goods Sold (CoGS) shall be $3000 USD or less.
When developing a more technical requirement it is recommended to include the spec to be used and the specific section. Template: The “thing” shall “provide” this to achieve “this” according to “spec” section based on industry standard. Example: The equipment shall survive, in a non-operating state and with no subsequent loss of functionality, exposure to the standard humidity environment, with the test methods specified in xxx, Section xxx.
More Recommendations On Writing Quality Requirements:
Requirements should be complete- a requirement needs to provide all the information necessary to implement it, includes conditions and states. Example: Environment, humidity- The device shall survive, in a non-operating state and with no subsequent loss of functionality, exposure to the standard humidity environment, with the test methods specified in xxx, Section xxx. Explain: this requirement includes the state the device should be during the test, the functionality and the standard to be used.
Requirements should be feasible- when writing and approving requirements, make sure the requirement states a realistic request. The unrealistic or infeasible requirement means future delays, an engineering change request and an impact analysis which are costly. Engineers can perform simulations to determine physical constrains, the product team should expect realistic time to market and costs, etc. it is always better to discuss and reject a requirement at the beginning of a project.
Requirements should be testable- requirements should be testable with a clear pass/fail result. The objective should have existed verifiable results.
Requirements should be tracible- requirement should allow a trail (parent or child requirement). This means a requirement should be linked to another parent requirement, a sub-requirement or a verification test case.
A Few More Comments/Ideas (the don’t):
1. I have seen/been in companies that manage requirements using a Word document/Excel sheet. I never consider this a best practice. There are a few requirement management tools that will ease the process and make this process more efficient.
2. The best practice verb term for requirements is shall. Try to avoid must, will or should.
3. Prioritizing requirements- some companies prioritize requirements using soft requirements, hard requirements or a nice-to-have. I recommend avoiding this and make sure a requirement is a requirement.
4. I used to develop features and requirements in the past. Based on my own best practice to control the project scope I recommend using requirements only. I will discuss scope creep in a future blog.
5. Don’t use conjunctions such as or/and in a requirement or combine a couple of requirements into a single requirement.
Don’t add a description of the requirement in the same statement. Maintain descriptions in a different section.
Comments