1. On the Requirements

The first topic I want to get a go with is the use of Use Cases. But, before I start on the use cases I would like to clear up some basics about the requirements.
I’ve met a lot of people for who there is only one kind of requirement: business requirements, every single one conforms to the same theoretical and well defined structure and can be documented in the same template.
I personally think that it is an oversimplification of the whole thing, and I think it usually means that:

1. half of the requirements are missing
2. a lot of different things are not recognized as requirements

I think that there are different kinds of requirements, with different goals and as it happens with different documentation needs -
I usually go with the Business Requirement, Functional Requirement, Functional Requirement distinctions and for me it works pretty well -, and in the literature about requirements there are different groupings and types listed. I will just look at two sources now, but I think those two are enough to prove this statement.

In Karl E. Wiegers: Software Requirements, Second Edition the requirements are grouped as follow:

• Business Requirements: Business requirements describe why the organization is implementing the system – the objectives the organization hopes to achieve.
• User Requirements: describe the user goals or tasks that the users must be able to perform with the product.
• System Requirements: describes the top-level requirements for a product that contains multiple subsystems.
• Functional Requirements: specify the software functionality that the developer must build into the product to enable users to accomplish their tasks.
• Business Rules: include corporate policies, government regulations, industry standards, accounting practices and computational algorithms.
• Quality Attributes: desired characteristics like usability, portability, integrity,efficiency, and robustness.
• External Interfaces: describe external interfaces between the system and the outside world.
• Constraints: restrictions concerning the development, restricting the choices available to the developer for design and construction of the product.

The Business Analysis Body of Knowledge (BABOK) lists the following types of requirements:

• Business Requirements: are higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.
• User Requirements: are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. User Requirements serve as a bridge between Business Requirements and the various classes of solution requirements.
• Functional Requirements: describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations-a specific system action or response.
• Quality of Service Requirements: capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as non-functional or supplementary requirements.
• Assumptions and constraints: identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution.
• Implementation requirements: describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.

The groupings overlap in several places, and are the results of long years of experience – in the case of BABOK long years of many people’s experience – so I think that it can be accepted that there is a real need for separating the different kind of requirements. Especially if you ever want to take the CBAP Exam, because that uses the BABOK as the course material.

But if we accept that there are different kind of requirements, with different goals, levels and content, then we have to admit that they need different documentation, different way to model and present them, and that they can not really be put in the same template.

That’s enough about laying down the basic assumptions about requirements, that I will use in the rest of the post, and we can move to the use cases.