Requirements Models

Software Requirements Knowledge

Model
Knowledge Model
Software requirements activity involves the interest of a
number of parties and stakeholders. This model tries to
capture them.
Stakeholders-
 Governors-Board Members, Corporate Officers,
Government Regulators.
 Requestors-Activity Managers, Solution Planners, Solution
Marketers.
 Expectors -Customers, Installers, Maintainers
Interests and Concerns-
 Value
 Relevance
 Profitability
 Growth
 Diversity
Software Requirements Conceptual
Model
Conceptual Model
 Level 0: Vision, Mission, Values
 Level 1: Business Activity
 Level 2: Activity Improvement
 Level 3: Solution Feature
 Level 4: Interaction Dialog
 Level 5: Solution Component
 Level 6: Development Project
Requirements Roadmap
Roadmap Model
This model answers the questions-
 How defines the requirements?
 Why the requirements are necessary?
 What are the requirements?
 When are the requirements needful?
 Where are the requirements necessary?
Physical Object Model (OOP)
Object Models
The physical object model treats each requirement as an object.

 Hardware-Hiding Modules. “Programs that need to be changed if any part

of the hardware is replaced.” Modules for which the encapsulated
information (secret) is “hardware / software interfaces.”

 Required Behavior-Hiding Modules. “Programs that need to be changed if

there are changes in the sections of the requirements document that
describe the required behavior.” Modules for which the encapsulated
information (secret) is “the content of those sections [of the requirements
document].”

 Design Decision-Hiding Modules. All other programs of the application.

Modules for which the encapsulated information (secrets) are “software
design decisions based upon mathematical theorems, physical facts, and
programming considerations such as algorithmic efficiency and accuracy . .
. not described in the requirements document.”
State Diagram Model
State Diagram Model
 Requirements can also be defined using
the state diagram.
 The state diagram depicts requirements
using the following methods-
1. Defining the processes.
2. Defining the flow of information.
3. Defining the information at each stage.
4. Defining the requirements of each process
and user.
Software Cost Reduction
Requirements Model
Specification
Editor Consistency Checker

Theorem Requirements
Simulator
Prover

Dependency Graph Invariant Generator

Browser
Cost Reduction Model
 Specification Editor. To create and modify a re-quirements specification, the user
invokes the specification editor. Each SCR specification is organized into dictionaries
and tables.
 Dependency Graph Browser. Understanding the relationship between different
parts of a large specification can be difficult. To address this problem, the
Dependency Graph Browser (DGB) represents the dependencies among the variables
in a given SCR specication as a directed graph
 Consistency Checker. The consistency checker analyzes a specication for
consistency with the SCRrequirements model. It exposes syntax and type errors,
variable name discrepancies, missing cases, no determinism, and circular definitions.
When an error is detected, the consistency checker provides detailed feedback to
facilitate error correction.
 Simulator. To validate a specication, the user can run the simulator [6] and analyze
the results to ensure that the specication captures the intended behavior.
 Theorem Prover. When model checking fails to reveal an error in a requirements
specication or produces many spurious counterexamples, the user may use
mechanical theorem proving to establish the property.
 Invariant Generator. Recently, a prototype tool that automatically generates state
invariants from SCR tables was integrated into SCR. This tool has generated more
than 20 interesting state invariants
Waterfall Model
Waterfall Model
 Emphasizes completion of one phase of development before
proceeding to the next phase; freeze the products of one phase
before proceeding to the next phase. Must use a formal change
mechanism to make requirements changes.

 Patterned after process models in other disciplines, making it easy

for managers to understand and accept. In this model each phase
is defined by a set of functions, goals, milestones, and deliverables,
making the process highly visible and the project easier to track.
Since requirements and specifications are determined at the
outset, the PM is better able to determine his or her resource
needs and establish schedules.

 Systems that have well-defined requirements at the outset and

systems where the costs and schedules need to be determined up
front.
Incremental Development
Incremental Development Model
 Performs the waterfall in overlapping sections.

 Requirements do not have to be fully specified/clarified at

onset. As each increment is completed, requirements are
clarified.

 Well-suited for systems where the requirements cannot be

specified.
Evolutionary Model
Evolutionary Model
 The development stage is done as a series of increments.
Each increment builds a subset of the full system. An
increment is a full life cycle of analysis, design, coding,
testing, and integration. It may be delivered to the user,
but not necessarily. If it is delivered, there may be some
finishing: optimization, packaging, and the like, after the
build.

 Is focused on early and continuous delivery of requirement

defined stakeholder value. Allows detailed requirements to
emerge gradually.

 Well suited for systems where requirements cannot be

specified
Spiral Model
Spiral Model
 Divides system development into four basic activities:
planning, risk analysis, engineering, and evaluation. Within
each spiral loop, risks are identified and attempts to
mitigate risk are made before proceeding to the
engineering activity of the spiral.

 Avoids some of the difficulties of existing software models

by using a risk-driven approach. Tries to eliminate errors in
early phases. Provides mechanisms for QA. Applicable to
other kinds of projects. Works well for a complex, dynamic,
innovative project. Reevaluation after each phase allows
changes in user perspectives, technology advances, or
financial perspectives.

 Complex, dynamic, innovative, ambitious projects carried

out in internal teams (not necessarily limited to software).
Unified Modeling Language
Unified Modeling Language
 The Unified Modeling Language or UML is a mostly graphical modeling
language that is used to express designs.  It is a standardized language in
which to specify the artifacts and components of a software system.  It is
important to understand that the UML describes a notation and not a
process.  It does not put forth a single method or process of design, but
rather is a standardized tool that can be used in a design process.
 The Use Case Diagram
In many design processes, the use case diagram is the first that designers
will work with when starting a project.  This diagram allows for the
specification of high level user goals that the system must carry out. 
These goals are not necessarily tasks or actions, but can be more general
required functionality of the system
 The Class Diagram The class diagram is core to object-oriented design.
 It describes the types of objects in the system and the static relationships
between them.
 Interaction Diagrams - Sequence and Collaboration
Once the use cases are specified, and some of the core objects in the
system are prototyped on class diagrams, we can start designing the
dynamic behavior of the system.
Black Box Model Of Requirements
Black Box Model
 The benefit of the black box definition of
requirements stems from the fact that, with
requirements defined as the black box view of the
system (i.e., its external interface), requirements
become encapsulatable.
 A requirements (i.e., external interface)
specification consists of:
1. All external stimuli of the system
2. All associated external responses
3. All external communication protocols
Enterprise Process Model
Enterprise Process Model
 Before automating a task or process, a model of the
customer’s current mission or business process should first
be developed. Usually this will be done as part of the
customer’s process improvement strategy when
determining the cost–benefit to the customer of additional
software.
The steps include-
 Build versus Buy
 Prioritize quality requirements
 Identify and Organize stimuli
 Sketch human user interface
 Depict external communication protocols
 Identify requirement commonalities
 Specify responses