Exact Requirements

From EUDP
Jump to: navigation, search

What

In engineering, a requirement is a singular documented need of what a particular product or service should be or perform.

The dish

Exact Requirements

Ingredients

Process

In order to specify the exact requirements you need to locate, analyse and describe the needs of the customer in an iterative process.

To locate the needs, you have to listen carefully to the customer's storytelling. A good tool is to draw a Rich Picture to get an understanding of the functionality. Then you analyse the information to get a structured picture of the problem. This analysis may include Preliminary Use Cases, System Definition and even Prototyping. Then you make a description and present it to the customer in order to secure that you have understood his needs correctly. You may have to go through this process several times before you are able to locate all the exact requirements. It is important that the requirements are:

1. unambiguous

2. complete

3. consistent

4. correct

5. measurable & testable

6. changeable

7. traceable

8. documented

9. actionable

10. defined to a level of detail sufficient for system design.

in order to make the verification and product accept easy and without conflicts.

See [1] for a more detailed explanation.


Splitting it up a bit

Exact Requirements can be split into following

Customer Requirements :

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS).

The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer.

Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

  • Operational distribution or deployment: Where will the system be used?
  • Mission profile or scenario: How will the system accomplish its mission objective?
  • Performance and related parameters: What are the critical system parameters to accomplish the mission?
  • Utilization environments: How are the various system components to be used?
  • Effectiveness requirements: How effective or efficient must the system be in performing its mission?
  • Operational life cycle: How long will the system be in use by the user?
  • Environment: What environments will the system be expected to operate in an effective manner?

Functional Requirements :

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished.

Functional requirements analysis will be used as the toplevel functions for functional analysis

Non-functional Requirements / Performance Requirements :

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours.

A non-functional requirement often describes a criteria for a systems performance, that can be measured and tested.

Behavioural requirements are typically captured in the Use Cases. A behavioural requirement utilises the functional requirements, that is put the functionality of the system in question. How the system-to-be reacts

In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.

* Functional requirements are usually in the form of "system shall do <requirement>"

* Non-functional requirements are "system shall be <requirement>"

* Behavioural requirements are "how the system shall react"

Why

We have to realise that it is a complicated and iterative process to identify the customer's needs. Especially the software can be highly abstract reasoning which might be difficult to understand for the customer. A process has input data, activity and output data. The pattern to locate the exact requirements is therefore:

  • Input data: The customer's description of his vision, his needs and the concept for the project.
  • Activity: Run through these activities repeatedly: Capture Requirements -> Analyse Requirements -> Specify Requirements -> Verify Requirements

Activity.gif

  • Output data: The result from the process will be a description of the exact requirements.

How

Before ending up with a list of requirements, a requirement analysis must be performed.

Example 1

Input data is the Rich Picture and the customer's description of his house heating and solar energy system.

Activity:

To capture the requirements from the input data. The system contains four main components:

1. The central heating with the boiler, motor-controlled mixer, pump, supply temperature sensor and radiators.
2. The hot water tank with the boiler, pump, the boiler-driven heating coil, the mains-driven heating coil and the relay to switch between the two coils.
3. The solar energy system
4. And additionally; the control system that the developer has to make according to the customer's description!

To analyse the requirements, the developer has to work through the customer's information and make a system description in his own words. This ensures that he has understood all of the customer's needs and he gets an idea of how to solve the problem and how to verify his solution.

To specify the requirements, the developer uses his solution and verification model.

Example 2

The DIY segway.

From customer interviews, the System Definition and the System Overview Diagram, following exact requirements are stated.

Customer Requirements :

Functional Requirements : Non-functional Requirements / Performance Requirements :

Todo:table:

parameter, value, unit allowed tolerance, +/-value, unit

Used In

The Exact Requirements are widely used in the systems development, but foremost they are used in the Product Acceptance, where the customer examines the delivery and eventually accept that the delivered conforms to the requirements.

From here you may want to jump on to General Architecture Design.