Requirements Specification
Before a system is designed and implemented, the requirements have to be
specified in enough detail to make analysis and design possible. This is
a big part of software engineering, especially for larger systems. (This
is also the part that we, as programmers, usually enjoy the least!!)
The course textbook attempts to delve into this process in great
detail. This outline is meant to give just a quick overview, without
going into the level of detail discussed in the textbook.
- Course textbook discusses this process in great detail
- We will just look at a quick overview of what could be involved
- More rigorous and detailed activities are involved for larger scale
systems.
- For smaller systems, less formal processes work.
Requirements Elicitation
- Often the customer only has a vague idea of the system they want
- Requirements Elicitation is the process of identifying the
requirements of a system, and formalizing them.
- Part of this process aims to create the functional model, which
can be specified with use cases
- This all focuses on the user's point of view (application domain)
- There are different ways to elicit the requirements of a system.
Sometimes more than one approach is needed. Just a few possibilities:
- observation of current processes
- questionairres
- interviews (e.g. of prospective users)
- market research (like for off-the-shelf products)
- information from subject-matter experts
Types of Requirements
- Functional Requirements
- Describe what the system actually does
- Describes intended interactions between users and the system,
independent of implementation
- Non-functional Requirements
- User-visible aspects of the system, not directly related to the
functional behavior.
- Some categories are: usability, reliability, performance (response
times, throughput, accuracy, etc), supportability
- Examples: response time must be less than second. Computed values
within a certain level of accuracy.
- Constraints ("pseudo-requirements")
- Imposed by the client or the environment in which the system is to
operate
- Examples: Must interface with an existing system, written 10 years
before. Implementation language must be Ada.
- Constraints actually are a form of non-functional requirements, but
they are often separated from the "quality" requirements
Requirements Analysis
Requirements can be tested and validated. A requirement specification
should be checked that it is:
- Complete -- all features of interest should be
described
- Consistent -- Two requirements should not contradict each
other
- Unambiguous -- A requirement should not be able to have
multiple interpretations
- Correct -- accurate representation of the system that the
client needs
- Realistic -- can it actually be implemented within
constraints?
- Verifiable -- can the system demonstrate that it satisfies all
requirements with repeatable tests?
- Traceable -- can each requirement be traced to a system
feature, and can each system function be traced back to a specific
requirement?
How to come up with the requirements
The techniques may vary with the company involved and with the level of
complexity of the desired system. Different companies have different
levels of formality in their processes.
One useful technique is to go from the specific to the general:
- Identify the actors
- Who (or what) will the user(s) of the system be?
- What external hardware or software does the system need to interact
with?
- Identify scenarios
- Remember, a scenario is a specific instance of a use case
- Can observe current user processes (even manual processes), or a
current system
- Generalize the scenarios to create use cases
- Identify communication with actors
- Complex use cases can often be broken up into multiple use cases,
with the include and/or extend relationships
- Identify participating objects
- This gives a little head start on analysis. What objects (conceptual
at this stage) are involved with each use case?
- Identify any non-functional requirements
Where to go from here?
- After requirements are specified, analysis is performed
- The requirements are more of a definition of the system in terms
understood by the client/customer
- Analysis yields a more technical specification of the system in terms
understood by the developer