Scribd
Upload
51 views25 pages

Introduction To Software Engineering: Understanding Requirements

This document provides an introduction to understanding software requirements. It discusses requirement elicitation through user scenarios, specification principles, representation formats, and the review process. Specifically, it describes eliciting requirements by creating user scenarios from the perspective of different actors. It also outlines principles for specifications being separate from implementation, tolerant of incompleteness, and revisable. Common representation formats and the structure of a software requirements specification are defined. The importance of reviewing specifications is emphasized for ensuring completeness, consistency, and accuracy.

Uploaded by

Sufyan Abbasi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
51 views25 pages

Introduction To Software Engineering: Understanding Requirements

This document provides an introduction to understanding software requirements. It discusses requirement elicitation through user scenarios, specification principles, representation formats, and the review process. Specifically, it describes eliciting requirements by creating user scenarios from the perspective of different actors. It also outlines principles for specifications being separate from implementation, tolerant of incompleteness, and revisable. Common representation formats and the structure of a software requirements specification are defined. The importance of reviewing specifications is emphasized for ensuring completeness, consistency, and accuracy.

Uploaded by

Sufyan Abbasi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 25

Introduction to Software Engineering

Understanding Requirements (3)

Muhammad Nasir
[email protected]
Agenda
 Requirement Elicitation
 User Scenario
 Specification Principles
 Specification Representation
 Specification Review
User Scenario
 It is difficult to move into more software
engineering activities until software team
understands how these functions and
features will be used by different end-
users.
 Developers and users create a set of usage
threads for the system to be constructed
 “A use-case scenario is a story about how
someone or something external to the
software (known as an actor) interacts with
the system”.
User Scenario
 Describe how the system will be used
 “Each scenario is described from the
point-of-view of an “actor”—a person or
device that interacts with the software in
some way”
 It is important to note that an actor and
an end user are not necessarily the
same thing.
SafeHome – Example
User Scenario
 A typical user may play a number of
different roles when using a system.
 Whereas an actor represents a class
of external entities (often, but not
always, people)
 that play just one role in the context of
the use case.
User Scenario
 After careful review of requirements,
the software for a Automated Control
System requires
 Four different modes (roles) for
interaction: programming mode, test
mode, monitoring mode, and
troubleshooting mode.
User Scenario
 Therefore, four actors can be defined:
programmer, tester, monitor, and
troubleshooter.
 In some cases, the machine operator
can play all of these roles.
 In others, different people may play the
role of each actor.
SafeHome – Usage Scenarios
 For the purposes of this example we
consider only the homeowner actor.
 Home Owner may interact with system in
following way
 Enters a password to allow all other interactions.
 Inquires about the status of a security zone.
 Inquires about the status of a sensor.
 Presses the panic button in an emergency.
 Activates/deactivates the security system.
SafeHome – Basic Use Cases
1. The home-owner observes the SafeHome control
panel to determine if the system is ready for input.
 If the system is not ready, a not ready message is
displayed on the LCD display, and the home-owner must
physically close windows or doors
 So that the not ready message disappears.
 [A not ready message implies that a sensor is open; i.e., that a door
or window is open.]
SafeHome – Basic Use Cases
 2. The homeowner uses the keypad to
input a four-digit password.
 The password is compared with the valid
password stored in the system.
 If the password is incorrect, the control panel will
beep once and reset itself for additional input.
 If the password is correct, the control panel
awaits further action.
SafeHome – Basic Use Cases
 The homeowner selects and input stay
or away to activate the system.
 Stay activates only perimeter sensors
(inside motion detecting sensors are
deactivated).
 Away activates all sensors
SafeHome – Basic Use Cases
 When activation occurs,
 A red alarm light can be observed by the
homeowner.
SafeHome – Detail Use Case
SafeHome – Detail Use Case
SafeHome – Detail Use Case
Specification Principles
If specification incomplete, inconsistent, or misleading
specifications result in confusion.
1. Separate functionality from implementation.

2. Develop a model of the desired behavior of a


system.
3. Establish the context in which software operates
by specifying the manner.
4. Define the environment in which the system
operates and indicate how.
Specification Principles (cont.)
5. Create a cognitive model rather than a
design or implementation model.
6. The specifications must be tolerant of
incompleteness.
7. Establish the content and structure of a
specification in a way that it could be easy
to change.
Specification Representation
 Representation format and content should be relevant to
the problem.
 For example, a specification for a manufacturing automation system
might use different diagrams and language than the specification for a
programming language compiler.
 Information contained within the specification should be
nested (layered).
 Paragraph and diagram numbering schemes should indicate the level of
detail that is being presented.
 It is sometimes worthwhile to present the same information at different
levels of abstraction to aid in understanding.
Specification Representation
 Diagrams and other notational forms should be restricted
in number and consistent in use.
 Confusing or inconsistent notation, whether graphical or symbolic,
degrades understanding and fosters errors.
 Representations should be revisable.
 It contains a complete information description, a detailed functional
description, a representation of system behavior, an indication of
performance requirements and design constraints, appropriate
validation criteria, and other information pertinent to requirements.
Software Requirements Specification
Format of SRS:
Introduction of the software requirements specification states the goals and
objectives of the software, describing it in the context of the computer-based
system.
Information content, flow, and structure are documented. Hardware, software,
and human interfaces are described for external system elements and internal
software functions.
Functional Description A processing narrative is provided for each function,
design constraints are stated and justified & performance characteristics are
stated
Behavioral Description operation of the software as a consequence of
external events and internally generated control characteristics.
Software Requirements Specification (Cont.)
Validation Criteria is probably the most important and, ironically, the
most often neglected section of the Software Requirements
Specification (SRS). Testing or validating each user-scenario.

Finally, the specification includes a Bibliography and Appendix. The


bibliography contains references to all documents that relate to the
software. The appendix contains information that supplements the
specifications
Specification Review
 A review of the SRS (and/or prototype) is conducted by both
the software development team and the customer.
 Conducted at a macroscopic level
 Ensure that specification is complete
 Consistent
 Accurate (Information, functional and behavioral
domain considered).
 Review becomes more detailed while examining Information,
functional and behavioral domain.
 Examining not only broad descriptions but the way in which
requirement worded.
E.g. Terms like “Vague ” (some, sometimes, often, usually) should
be flag by reviewer for further clarification.
Review (cont.)
 Once review is complete – SRS “signed off” by both
customer and vendor. ( “contract” for software
development)
 Requests for changes in requirements after the
specification is finalized will not be eliminated.
 Change is an extension of software scope and therefore
can increase cost and/or delivery time of product.
 During the review, changes to the specification may be
recommended.
 It can be extremely difficult to assess the global impact of a
change; that is, how a change in one function affects
requirements for other functions
The End
 Thanks for listening
 Questions would be appreciated.

You might also like