Requirements

A software requirement specifies a need to be fulfilled by the software product.

A software project may be one of two types:

• a brownfield project, i.e., a project to replace or update an existing software product
  Example Adding an online payment option to a university's existing course registration system.
• a greenfield project, i.e., a project to develop a new system from scratch
  Example Building a new app that lets students swap tutorial slots, where no such system exists yet.

In either case, requirements need to be gathered, analyzed, specified, and managed.

Requirements come from stakeholders.

Identifying requirements is often not easy.
Example Stakeholders may not be aware of their precise needs, may not know how to communicate their requirements correctly, or may not be willing to spend effort identifying requirements.

Requirements can be divided into two in the following way:

1. Functional requirements specify what the system should do.
   Example The system should allow a user to search for a book by its title.
2. Non-functional requirements specify the constraints under which the system is developed and operated.
   Example The search should return results within two seconds.

Example Some categories of non-functional requirements:

• Data requirements, e.g., size, , , etc.
• Environment requirements, e.g., the technical environment in which the system would operate or with which it needs to be compatible.
• Performance, Security, Usability, Interoperability, Maintainability, Compliance with regulations, and more ...

Example Some concrete NFRs, drawn from various projects:

• Business/domain rules: the size of the minefield cannot be smaller than five.
• Constraints: system testers are available only during the last month of the project.
• Performance requirements: the system should respond within two seconds.
• Quality requirements: the system should be usable by a novice who has never carried out an online purchase.
• Process requirements: the project is expected to adhere to a schedule that delivers a feature set every month.

You may have to spend extra effort identifying NFRs as early as possible because:

1. NFRs are easier to miss.
   Example Stakeholders tend to think of functional requirements first.
2. Sometimes NFRs are critical to the success of the software.
   Example A web application that is too slow or that has weak security is unlikely to succeed even if it has all the right functionality.

Requirements can be prioritized based on the importance and urgency, while keeping in mind the constraints of schedule, budget, staff resources, quality goals, and other constraints.

A common approach is to group requirements into priority categories. Note that all such scales are subjective, and stakeholders define the meaning of each level in the scale for the project at hand.

Example One scheme for categorizing requirements:

• Essential: The product must fulfill this requirement; otherwise, users will not accept it.
• Typical: Most similar systems have this feature although the product can survive without it.
• Novel: New features that could differentiate this product from the rest.

Other schemes:

• High, Medium, Low
• Must-have, Nice-to-have, Unlikely-to-have
• Level 0, Level 1, Level 2, ...

Some requirements can be discarded if they are considered ‘out of ’.

Example The requirement given below is for a Calendar application. Stakeholders of the software (e.g., product designers) might decide it is outside the software's scope.

The software records the actual time taken by each task and shows the difference between the actual and scheduled time for the task.

Here are some characteristics of well-defined requirements ^{[📖 zielczynski]}:

• Unambiguous
• Testable (verifiable)
• Clear (concise, terse, simple, precise)
• Correct
• Understandable
• Feasible (realistic, possible)
• Independent
• Necessary
• Implementation-free (i.e., abstract)

Two of these carry most of the weight: a requirement that is unambiguous and testable states an observable result, so evidence can settle whether it has been met. A requirement that states a judgment instead can only be settled by argument. To make one testable, say who is involved, what they are doing, and what result counts as success.

Example Two requirements from the same project, one testable and one not:

• Good The system should respond within two seconds. You can measure this, and the measurement settles the matter.
• Bad The system should be usable by a novice who has never carried out an online purchase. Two people can disagree about whether the system is 'usable', and neither can show the other is wrong.

The second can be rewritten so that evidence settles it:

• Good A user who has never carried out an online purchase should be able to complete a purchase unaided, on the first attempt, within five minutes.

Besides these criteria for individual requirements, the set of requirements as a whole should be:

• Consistent
• Non-redundant
• Complete

Requirements are not settled once and then left alone; they keep changing while the product is being built. Three reasons account for most of it:

1. Stakeholders work out what they want by seeing something concrete.
   Example A user who could not describe the report they needed can say exactly what is wrong with the first version of it.
2. The world the product lives in changes.
   Example A new regulation comes into force, or a competitor ships a feature that users now expect.
3. The team learns what things actually cost.
   Example A requirement turns out to take ten times the effort everyone assumed, which changes whether it is worth having at all.

Two things follow from this.

A specification that is not kept up to date does not become harmless, it becomes misleading, because people keep acting on it. A developer builds the version that was superseded a month ago; a tester reports a defect against behavior nobody wants any more.

Every change is also a decision about what will not be built. Accepting a new requirement late competes with requirements already agreed, so priorities have to be revisited rather than settled once at the start.