- What is the difference between functional and business requirements
- How can you have 'optonal requirements'
- Where does solution agnostic requirement spec end and design begin
- What do we mean by 'business'
- Hell, what do we mean by 'analysis'
There is another definition of operational requirements:
1) Operational requirements are systems requirements that specify how the system must operate
2) Maintenance requirements (not maintainability requirements) that specify how a system (not just software) must be maintained (e.g., replacement of parts)
3) Sustainment requirements that specify how a system must be sustained (e.g., supplied with fuel)
4) Retirement requirements that specify how a system must be retired from service (e.g., disposal of hazardous materials).
It's a nice alternative to the way many of us think about requirements.
As an aside, I have been reflecting on the differences in types of requirements statements recently. In particular I have been sitting in review meetings discussing User Stories where I note two characteristics.
User stories are stuctured to be focused on capabilities, with an orientation to particular user types. This means that they can be quickly assessed to determine whether they are solution agnostic or assuming particular solution contexts. Also - since you are responding to a tangible emerging system there are often opportunities to go straight to a solution option.
An example: -As a customer-I want to be able to open up a search result and see more product details-so that...
This example may be a bit vagiue for you, but the people in the room know exactly what this means for an implementation.