Browse Source

sem2/reqs_eng: add reqs.md

trunk
Callum R. Renwick 5 months ago
parent
commit
6965250caa
  1. 104
      sem2/reqs_eng/reqs.md

104
sem2/reqs_eng/reqs.md

@ -0,0 +1,104 @@
# Requirements
Requirements should be:
* Detailed
* Unambiguous
* Complete (that is, not missing anything)
* Understandable (clear)
* Testable (it must be possible to measure whether a requirement has been met)
* Necessary (don't include requirements which aren't required, obviously)
* Attainable (requirements should be possible to fulfill)
* Independent (each requirement should be distinct and separate from other requirements)
* Non-redundant (requirements should not cover things already covered by other requirements)
## Requirements Specifications
A **requirements specification** is a document which records the requirements for a system. In principle
these documents should always be **complete** (documenting *all* the requirements for a system) and
**consistent** (never self-contradictory), although in practice achieving this perfectly is impossible.
A requirements specification usually includes both user and system requirements (see below).
A requirements specification is *not a design document*, meaning that it should set out *what the system
should do* rather than *how it should do it*. That would overreach the scope of requirements.
## Kinds of Requirement
### Functional requirements
These are statements of services that the system should provide, how the system should react to particular
inputs and how the system should behave in particular situations.
### Non-functional requirements
Constraints on the services or functionality offered by the system: for example, timing constraints,
constraints on the development process, standards, *etc.* Non-functional requirments often apply to
the system *as a whole*, rather than individual features or services. They also often create other
requirements by existing (because some non-functional requirements may imply other functional or
non-functional requirements).
The difference between these types of requirement is that non-functional requirements are not needed
by the user directly, but are nevertheless required because they must be met for the system to work properly
or according to regulations.
There are two other kinds of requirement which overlap with functional and non-functional. They are:
### User requirements
Requirements aimed at the end-user. They *make the user the subject* and typically consist of statements in
*natural language*, plus *diagrams* of the services the system provides and its operational constraints.
### System requirements
Requirements aimed at the system designers and maintainers. They are contained within a *structured document*
which sets out *detailed descriptions* of the system's functions, services and operational constraints. These
requirements define what *will and will not be implemented* and so may be part of a contract between a client
and a contractor. They make the *system itself the subject*.
User requirements are likely to be more abstract than system requirements because the user only generally cares
about what functionality they have access to and not the full scope of the system's requirements.
System requirments are written for the stakeholders in the system's *development*, so they are designed to be
more precise, although they shouldn't specify implementation details (this goes beyond the scope of requirements).
They describe exactly what the system should do.
### Domain requirements
Domain requirements are a subtype of non-functional requirements which come with the **application domain** of the
software system. For example, a software system dealing with railway train bookings must follow any applicable
laws or regulations about rail travel, as well as codes of conduct or convention for the rail industry.
# Requirements Engineering
Requirements engineering is about:
* what software can do (that is, what problems software can solve)
* what software *does* do
* communicating these things to people
## Stages of Requirements Engineering
### Requirements Elicitation
Getting the requirements
### Requirement Specification
Writing down the requirements
### Requirement Validation
Checking that all **stakeholders** agree with the requirements
(**Stakeholders** are people who care about the software system.
They include the end users as well as the client org if
software is being developed for another organisation.)
# Stages of Software Design
1. Requirements: what must the software do
2. Design: how shall it do that
3. Implementation: how does it do that
4. Verification: does it, in fact, do that
5. Maintenance: does it still do that / can it now do this
Loading…
Cancel
Save