Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended for specifying software requirements in IEEE standard 830, and still are in 29148:2011.
The IEEE standard for software requirements specification recommends this method as they have many advantages . They are very granular, enabling a team to express need extremely concisely. This means that development metrics, like defect per requirement, requirement test coverage, and requirement churn are much more meaningful than in an environment that relies on user stories, scenarios or use cases. IEEE statements also use a standard syntax, defined quite concisely in the IEEE standard, which helps alleviate the confusion in interpretation and expression that can occur when multiple authors and consumers are involved.
The system shall enable a travel agent to select a time period to reserve a room
The system shall enable a travel agent to select a type of room when reserving a room
The system shall inform a travel agent when the requested room type is not available on one or more days requested
The system shall provide the travel agent with a list of room types available at a property when the agent wants to reserve a room.
Another strength is that they lend themselves well to iterative development and to hierarchical organization. Being able to ‘layer’ requirements in this fashion enables organisations to manage complexity in large projects. Requirements can be grouped into features, releases, and products, and they can be added, removed and prioritized and support planning effort at a very granular level.
They do have disadvantages however. A moderate sized project, with 4-6 months of work, can easily have 400 requirement statements. One cell phone producer I worked with had close to 10 000 requirements for each product. This demands the use of a requirement management solution, especially when organizing them into a hierarchy and managing traceability to the code that satisfies the requirement and the tests that verify it is satisfied. If you or your organisation is attempting to use IEEE statements managed in a spreadsheet, I do not envy you.
IEEE statements have another drawback when specifying systems that automate business process. A list of 400 requirement statements is a very difficult read and gives the developer no context with which to design a solution. Without context it can be very hard to identify what the statement refers to at all, no matter how well written.
I’ve also seen requirement statements’ hierarchy leading to analysis paralysis, where analysts and designers spend more time arguing over the correct hierarchy and categorization than understanding and satisfying the need.
When would I recommend the use of IEEE statements alone? Only in situations where context is not crucial to understand the need. I’ve seen them used very effectively in technical product development, such as the design of engine control systems, medical imaging devices and so on, where requirements are more often a description of a technical constraint rather than the automation of process. If your requirements read like the following, IEEE requirement statements will suffice most of the time:
- The system shall broadcast and receive signals on GSM 900.
- The battery shall be completely recharged from flat in less than 2 hours from a powered USB 2.0 connection.
- The system shall encrypt 300MB of standard text in less than 100 Milliseconds
If you’re specifying a system that automates or supports processes and user interactions, IEEE statements alone are not sufficient. However, they’re extremely useful when combined with context, such as with use cases, scenarios or business activity and other process and information descriptions. Simply breaking a use case’s paths into requirement statements can break down a large piece of functionality into manageable pieces, which alleviates the problems with prioritization and planning of development work I mentioned use cases having. In my consulting, I always provide use case descriptions with requirement statements. This increases the amount of upfront work, but satisfies the client’s need to be able to understand the requirements, the designer’s need to have context, and the PMs need to assign and plan work.