3 levels of requirements

I picked this concept up from a discussion on the Yahoo Requirements Engineering Group and thought it may be interesting to you.

According to the boffins requirements have 3 levels; business, user and system. Each of them focus on a different aspect of the problem at hand. For example; business requirements are usually about defining the business problem and target outcome.

Let me quote Keither Collyer from the thread to explain it further.

"This division into three types of requirement is very common and is partof standard practice for a good many organizations. It is what Igenerally recommend with my customers. Although each of these threetypes could be divided further (and often should be), there are clearconceptual divisions between them.

They are far from being meresupplementary types.Summarizing what Gottesdiener writes (my words, not hers);

• Business requirements describe business needs. They don't say anything directly about the system. Without business needs, there is no reason to develop the system. This is a high level definition of theproblem to be solved.
• User requirements (or, more generally, stakeholder requirements) describe what users (and others) must get from the system in order toachieve the business needs. These are primarily about what the stakeholders will be able to achieve. This is again about the problem tobe solved, but at a more detailed level.
• Software requirements (or, more generally, system requirements) define what the system must do in order to satisfy the stakeholder requirements.You can think of these levels as "why are we building it, what it must achieve and how it will achieve it."

In a sense, business and user requirements are both forms of stakeholder requirements. But the difference is still worth maintaining.

It is arguable that there might well be various levels of system requirement, for example, if the highest level leads to a design, then the various elements of that design (sub-systems) will have their own system requirements - but these are not a conceptually separate type of requirement, they are still about what the (sub-) system must do."

Got something to say?

Name (required)

Email Address (required)

Website

Speak your mind