Hand-outs for Software Engineering

Compiled by: Ms. Marivic R. Mitschek

Chapter 4: Capturing the requirements
• Requirement: a feature of the system or a description of something the system is capable of
doing in order to fulfill the system’s purpose
• Requirements elicitation
– Especially a critical part of the process

Requirements
Requirements elicitation and definition and
analysis specification

Problem Problem Prototyping and Documentation

Analysis Description Testing and Validation

How we How we captured Is the function How we

captured all all the user feasible? captured what
the user need? need? the user
The process of determining requirements expects?

Levels of requirement definition:

1. user requirements – in a natural language plus diagrams, of what services the
system is expected to provide and the constraints under which it must operate
2. system requirements – set out the system and services and constraints in
detail.
3. software design specifications – an abstract description of the software design
which is a basis for more detailed design and implementation
Ex:
User and system requirements
User requirement definition
1. The software must provide a means of representing and accessing external files
created by other tools.
System requirements specification
1.1 The user should be provided with facilities to define the type of external files.
1.2 Each external file type may have an associated tool which may be applied to the file.
1.3 Each external file type may be represented as a specific icon on the user’s display.
1.4 Facilities should be provided for the icon representing an external file type to be defined by the
user.
1.5 When a user selects an icon representing an external file, the effect of that selection is to apply
the tool associated with the type of the external file to the file represented by the selected icon.
• Three kinds of requirements:
– those that absolutely must be met
– those that are highly desirable but not necessary
– those that are possible but could be eliminated
Requirements documents
• Requirements definition: complete listing of what the customer expects the system to do
• Requirements specification: restates the definition in technical terms so that the designer can
start on the design
• Configuration management: supports direct correspondence between the two documents
Configuration management
• Set of procedures that track
– requirements that define what the system should do
– design modules that are generated from requirements
– program code that implements the design
Hand-outs for Software Engineering
Compiled by: Ms. Marivic R. Mitschek
– tests that verify the functionality of the system
– documents that describe the system
Functional vs. non-functional requirements
• Functional: describes an interaction between the system and its environment
• Examples:
– System shall communicate with external system X.
– What conditions must be met for a message to be sent
• Non-functional: describes a restriction or constraint that limits our choices for constructing a
solution
• Examples:
– Paychecks distributed no more than 4 hours after initial data are read.
– System limits access to senior managers.
Classification of non-functional requirements
 Product requirements – specify product behavior
 Organizational requirements – derived from policies and procedures
 External requirements – covers all requirements which are derived from factors external
to the system and its development process
Characteristics of requirements
• Are they correct?
• Are they consistent?
• Are they complete?
• Are they realistic?
• Does each describe something the customer needs?
• Are they verifiable?
• Are they traceable?
Prototyping requirements
• Throw-away prototypes
• Evolutionary prototypes
• Rapid prototypes
Requirements documentation
• Requirements definition document: what the customer wants
– general purpose
– background and objectives of system
– description of customer-suggested approach
– detailed characteristics
– operational environment
• Requirements specification document: what the designers need to know
Participants in requirements process
• Contract monitors, who suggests milestones and schedules that constrain the system
development
• Customers and users, who must understand the requirements so that they can be sure the
system will meet their needs
• Business managers, who must understand the likely consequences of building and using the
system
• Designers, who use the requirements as a basis for developing an acceptable solution that
will be implemented as a software-based system
• Testers, who develop test data and test suites to ensure that the software system satisfies
each requirement
• Requirements analysts
Hand-outs for Software Engineering
Compiled by: Ms. Marivic R. Mitschek