Levels of software
requirements

Articles

The intention of this article is to enumerate the levels of software requirements.

There are 3 levels of requirements

The word “requirements” means different things to different people. That is, if you speak to a user and ask what is requirements and if you speak to a developer then you will have a different meaning of the word requirements. Therefore, I prefer to speak of different levels of requirements. The business requirements can be broken in one or more user and functional requirements.

Level 1: Business requirements

It is high-level objectives of the organization or customer requesting the system or product and you place that in the scope document. Example, the organization needs to establish an online customer portal that will list our products.

Level 2: User requirements

They describe the tasks that users must be able to perform using the new product. These are best captured in the form of use cases.

Level 3: Functional requirements

You extract and derive functional requirements from the use cases. Example, if we take the business requirement,” the organization needs to establish an online customer portal that will list our products”. This can be broken in:

  • The system should support up to 5 pictures by product
  • The system should register a product by name, description, price, category

I want also to specify that a good document of requirements should include a section for non-functional requirements. Sufficient network bandwidth may be a non-functional requirement of a system.

These concepts can be illustrated with the following diagram:

I want also that a business analyst must prioritize requirements to focus on the most important requirements. A good tool for this is the MoSCoW analysis. It divides requirements into four categories: Must, Should, Could, and Won’t.

Must: Describes a requirement that must be satisfied. It is a mandatory requirement for the software to be considered a success.

Should: Represents a high-priority item that should be included in the solution fi it is possible to realize.

Could: Describes a requirement which is considered desirable but not necessary. We must considere time and resources.

Won’t: Represents a requirement that stakeholders have agreed will not be implemented in the current release, but can be considered for the future.

In conclusion, it is important to understand that there is a hierarchy in the levels of requirements.

Oracle® & Oracle® E-Business Suite
are registered trademarks of Oracle Corporation