SOFTWARE ENGINEERING

UNIT I :
Introduction to Software Engineering : The evolving role of software, software, The Changing Nature of
Software, Software engineering, A process Framework, Process patterns, process assessment, personal and
team process models, Process Technology, Product and Process.

Process models: Prescriptive models, The waterfall model, Incremental process models, Incremental
Process models, Evolutionary process models, Specialized process models.

Requirements Engineering: Requirements Engineering Task, Initiating the Requirements Engineering

process, Eliciting Requirements, Developing use cases, Building the analysis model, Negotiating
Requirements, Validating Requirements, Software Requirement Document (Sec 4.2)

1. INTRODUCTION TO SOFTWARE ENGINEERING

 What is Software?
 Computer Software is the product that software professional design and built. It includes
• Programs

• Content

• Documents

 What is software engineering?

• Related to the process: a systematic procedure used for the analysis, design,
implementation, test and maintenance of software.
• Related to the product: the software should be efficient, reliable, usable, modifiable,
portable, testable, reusable, maintainable, interoperable, and correct.

 The definition in IEEE Standard:

• The application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software, that is, the application of
engineering to software.

• The study of approaches as in 1993: The Joint IEEE Computer Society and ACM
Steering Committee for the establishment of software engineering as a profession.

 Why is it important and what are the steps?

-1-
  Software affects nearly every aspect of our lives. (data).
 You build software like you build any successful product, by applying a process that leads
to a high-quality result.
 You apply a software engineering approach.

 What is the work Product?

 From the point of view of a software engineer, the work product is the programs,
documents, and content.
 From the user’s viewpoint, the work product is the resultant information that somehow
makes the user’s world better.
 The Product

• Is the engine that drives business decision making.

• Software serves as the basis for modern scientific investigation and engineering
problem solving.
• It is embedded in systems of all kinds: transportation, medical, telecommunications,
military, industrial processes, entertainment, office products…

THE EVOLVING ROLE OF SOFTWARE

 Software’s Dual Role

 Software is a product
• As a product, it delivers computing potential embodied by computer hardware or broadly, by a
network of computers that are accessible by local hardware.
• Produces, manages, acquires, modifies, displays, or transmits information.

 Software is a vehicle for delivering a product

• Supports or directly provides system functionality
• Controls other programs (e.g., an operating system)
• Effects communications (e.g., networking software)
• Helps build other software (e.g., software tools)

 The Law of Continuing Change (1974): E-type systems must be continually adapted else they
become progressively less satisfactory.

 The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases
unless work is done to maintain or reduce it.

 The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with
distribution of product and process measures close to normal.

 The Law of Conservation of Organizational Stability (1980): The average effective global
activity rate in an evolving E-type system is invariant over product lifetime.

 The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with
-2-
 it, developers, sales personnel, users, for example, must maintain mastery of its content and
behavior to achieve satisfactory evolution.

 The Law of Continuing Growth (1980): The functional content of E-type systems must be
continually increased to maintain user satisfaction over their lifetime.

 The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining
unless they are rigorously maintained and adapted to operational environment changes.

 The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-
loop, multi-agent feedback systems and must be treated as such to achieve significant
improvement over any reasonable base.

SOFTWARE CHARACTERISTICS

 Software is developed or engineered; it is not manufactured in the classical sense.

 Software does not wear out.

Failure curve for software (idealized and actual curves)

 Most software is custom-built, rather than being assembled from existing components.

 Software Components

 In the hardware world, component reuse is a natural part of the engineering process.
 In the software world, it is something that has yet to be achieved on a broad scale.
 Reusability is an important characteristic of a high-quality software component.
 A software component should be designed and implemented so that it can be reused in many
different programs.
 In the 1960s, we built scientific subroutine libraries that wear reusable in a broad array of
engineering and scientific application.
 These subroutine libraries reused well defined algorithms in an effective manner, but had a
limited domain of application.
 Today, we have extended our view of reuse to encompass not only algorithms, but also data
structures.

-3-
 THE CHANGING NATURE OF SOFTWARE

Software Applications

 System software: system software is collection of programs written to service other programs.
E.g. Compilers, editors, file management utilities, operating systems, drivers, networking etc.

 Application software: Application software consists of standalone programs that solve a

specific business need. E.g. Point of sole transaction processing, real time manufacturing
control etc.

 Engineering/scientific software: Computer-aided design, system simulation, and other

interactive applications have begun to take on real-time and even system software
characteristics.

 Embedded software: Embedded software resides within a product or system and is used to
implement and control features and functions for the end-user and for the system itself.
Embedded software can perform limited and esoteric functions. e.g. digital functions in an
automobile such as fuel control, dashboard displays, braking systems, etc.

 Product-line software: Designed to provide a specific capability for use by many different
customers product-line software can focus on a limited and esoteric marketplace or address
mass consumer markets. e.g. inventory control, word processing, spreadsheets, computer
graphics, multimedia etc.

 WebApps (Web applications): “WebApps,” span a wide array of applications. In their simplest
form, webApps can be little more than a set of linked hypertext files that present information
using text and limited graphics.

 AI software: Al software makes use of non numerical algorithms to solve complex problems
that are not amenable to computation or straight forward analysis. e.g. robotics.

 Software—New Categories

 Ubiquitous computing: wireless networks

 Net sourcing: the Web as a computing engine

 Open source: ”free” source code open to the computing community (a blessing, but also a
potential curse!)

 Also …
• Data mining

• Grid computing
-4-
 • Cognitive machines

• Software for nanotechnologies

SOFTWARE MYTHS
 Unlike ancient myths, software myths propagate misinformation and confusion that have
caused serious problems for managers, technical people and customers.

Management Myths

 Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need to
know?

 Reality: The book of standards may very well exist, but is it used? Is it
complete? In many cases, the answer is no.

 Myth: If we get behind schedule, we can add more programmers and catch
up.

 Reality: Software development is not a mechanistic process like

manufacturing.

 Myth: If we decide to outsource the software project to a third party, I can

just relax and let that firm build it.

 Reality: If an organization does not understand how to manage and control

software projects internally, it will invariably struggle when it out sources
software projects.

Customer Myths

 Myth: Project requirements continually change, but change can be easily

accommodated because software is flexible.

 Reality: It is true that software requirements do change, but the impact of

change varies with the time at which it is introduced.

 Myth: A general statement of objectives is sufficient to begin writing

programs we can fill in the details later.

-5-
  Reality: Although a comprehensive and stable statement of requirements is
not always possible, an ambiguous statement of objectives is a recipe for
disaster.
Practitioner’s Myths

 Myth: Once we write the program and get it to work our job is done.

 Reality: “The sooner you begin writing code, the longer it’ll take you to get
done.” Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the customer
for the first time.

 Myth: Until I get the program running, I have no way of assessing its quality.

 Reality: One of the most effective software quality assurance mechanisms

can be applied from the inception of a project-the formal technical review.

 Myth: The only deliverable work product for a successful project is the
working program.

 Reality: A working program is only one part of a software configuration that

includes many elements.

 Myth: Software engineering will make us creates voluminous and

unnecessary documentation and will invariably slow us down.

 Reality: Software engineering is not about creating documents. It is about

creating quality. Better quality leads to reduced rework.

-6-
 2. A GENERIC VIEW OF PROCESS

 Chapter Overview

 What is it? A software process-a series of predictable steps that leads to a timely, high-
quality product.

 Who does it? Managers, software engineers, and customers.

 Why is it important? Provides stability, control, and organization to an otherwise chaotic

activity.

 What are the Steps? A handful of activities are common to all software process, details vary.

 What is the work product? Programs, documents, and data.

 Correct process? Assessment, quality deliverable.

SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY

 Focus on quality: must rest on an organizational commitment to quality.

 Process model: foundation for SE is the process layers, a frame work, models documents,
data, reports etc.

 Methods: how to’s, communication, requirement analysis design modeling program

connection, testing and support.

 Tools: provide automated or semi automated support for the process and methods.

-7-
A PROCESS FRAMEWORK

 Process framework

 Framework activities
• Work tasks
• Work products
• Milestones & deliverables
• QA checkpoints
• Umbrella Activities

Framework Activities

 Communication: This framework activity involves heavy communication and collaboration

with the customer and encompasses requirements gathering and other related activities.

 Planning: It describes the technical tasks to be conducted, the risks that are likely, the
resources that will be required, the work products to be produced, and a work schedule.

 Modeling: This activity encompasses

• Analysis of requirements
• Design

 Construction: This activity combines

• Code generation
• Testing

 Deployment: The software is delivered to the customer who evaluates the delivered product
and provides feedback based on the evaluation.

-8-
 Umbrella Activities

 Software project tracking and control: allows the software team to assess progress against
the project plan and take necessary action to maintain schedule.

 Formal technical reviews: Assesses software reengineering work products in an effort to

uncover and remove errors before they are propagated to the next action or activity.

 Software quality assurance: Defines and conducts the activities required to ensure software
quality.

 Software configuration management: manages the effects of change throughout the

software process.

 Work product preparation and production: encompasses the activities required to create
work products such as models, documents, logs, forms, and lists.

 Reusability management: defines criteria for work product reuse and establishes
mechanisms to achieve reusable components.

 Measurement: defines and collects process, project, and product measures that assist the
team in delivering software that meets customers’ needs; can be used in conjunction with
all other framework and umbrella activities.

 Risk management: assesses risks that may affect the outcome of the project or the quality of
the product.

 The Process Model: Adaptability

 the framework activities will always be applied on every project ... BUT

 the tasks (and degree of rigor) for each activity will vary based on:
• the type of project
• characteristics of the project
• common sense judgment; concurrence of the project team

THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

 The CMMI defines each process area in terms of “specific goals” and the “specific practices”
required to achieve these goals.

• Specific goals establish the characteristics that must exist if the activities implied by
a process area are to be effective.

-9-
 • Specific practices refine a goal into a set of process-related activities.

 The CMMI represents a process meta-model in tow different ways: (1) as continuous model
and (2) as a staged model.

 Capability levels:

• Level 0: Incomplete. The process area is either not performed or does not achieve all
goals and objectives defined by the CMMI for level 1 capacity.

• Level 1: Performed. All of the specific goals of the process area have been satisfied.
Work tasks required to produce defined work products are being conducted.

• Level 2: Managed. All level 1 criteria have been satisfied. In addition, all work associated
with the process area conforms to an organizationally defined policy; all people doing
the work have access to adequate resources to get the job done; stakeholders re
actively involved in the process area as require; all work tasks and work products are
“monitored, controlled, and reviewed; and are evaluated for adherence to the process
description”

• Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is
“tailored from the organization’s set of standard processes according to the
organization’s tailoring guidelines, and contributes work products, measures, and other
process-improvement information to the organizational process assets”

• Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, the
process area is controlled and improved using measurement and quantitative
assessment. “Quantitative objectives for quality and process performance are
established and used as criteria in managing the process”

• Level 5: Optimized. All capability level 4 criteria have been achieved. In addition, the
process area is adapted and optimized using quantitative means to meet changing
customer needs and to continually improve the efficacy of the process area under
consideration”.

PROCESS PATTERNS

 Process patterns define a set of activities, actions, work tasks, work products and/or related
behaviors.

 A template is used to define a pattern.

 Typical examples:
• Customer communication (a process activity)

- 10 -
• Analysis (an action)

- 11 -
 • Requirements gathering (a process task)
• Reviewing a work product (a process task)
• Design model (a work product)

PROCESS ASSESSMENT

 The process should be assessed to ensure that it meets a set of basic process criteria that
have been shown to be essential for a successful software engineering.

Software Process

identifies is examined by identifies capabilities

modifications to and risk of

Software Process
Assessment

leads to leads to Capability

Software Process Determination
Improvement
motivates

 Many different assessment options are available:

• SCAMPI: provides a five-step process assessment model that incorporates initiating,

diagnosing, establishing, acting, and learning.

• CBA IPI: provides diagnostic technique for assessing the relative maturity of a
software organization.

• SPICE: standard defines a set of requirements for software process assessment.

• ISO 9001:2000: for software is a generic standard that applies to any organization
that want improve the overall quality of the product systems, or services that it
provides.

- 12 -
 3. PROCESS MODELS

 Prescriptive Models

 Prescriptive process models advocate an orderly approach to software engineering.

 That leads to a few questions …

• If prescriptive process models strive for structure and order, are they inappropriate
for a software world that thrives on change?

• Yet, if we reject traditional process models (and the order they imply) and replace
them with something less structured, do we make it impossible to achieve
coordination and coherence in software work?

The Waterfall Model

 The Waterfall model sometimes called the classic life cycle, suggests a systematic, sequential
approach to software development.

- 13 -
 It is a oldest paradigm for software engineering.

 Most widely used though no longer state-of-art.

 Each step results in documentation.

 May be suited to for well-understood developments using familiar technology.

 Not suited to new, different systems because of specification uncertainty.

 Difficulty in accommodating change after the process has started.

 Can accommodate iteration but indirectly.

 Working version not available till late in process.

 Often get blocking states.

THE INCREMENTAL PROCESS MODELS

 There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort precludes a purely linear process.

 In addition, there may be a compelling need to provide a limited set of software

functionality to users quickly and then refine and expand on that functionality in later
software releases.

 In such cases, a process model that is designed to produce the software in increments is
chosen.

 The Incremental Model

 Applies an iterative philosophy to the waterfall model.

 Divide functionality of system into increments and use a liner sequence of development on
each increment.

 First increment delivered is usually the core product, i.e. only basic functionality.

- 14 -
 Reviews of each increment impact on design of later increments.

 Manages risk well.

 Extreme Programming (XP), and other Agile Methods, are incremental, but they do not
implement the waterfall model steps in the standard order.

 The Rapid Application Development (RAD) Model

 Similar to waterfall but uses a very short development cycle (60to90 days to completion).

 Uses component-based construction and emphasizes reuse and code generation.

 Use multiple teams on scaleable projects.

 Requires heavy resource.

 Requires developers and customers who are heavily committed.

 Performance can be a problem.

 Difficult to use with new technology

- 15 -
EVOLUTIONARY MODELS

 Evolutionary models are iterative. They are characterized in a manner that enables software
engineers to develop increasingly more complete versions of the software.

 Prototyping

 Ideally mock-up serves as mechanism for identifying requirements.

 Users like the method, get a feeling for the actual system.

 Less ideally may be the basis for completed.

• Prototypes often ignore quality/performance/maintenance issues.

• May create pressure from users on deliver earlier.

- 16 -
 • May use a less-than-ideal platform to deliver e.g Visual Basic – excellent for
prototyping, may not be as effective in actual operation.

 Specifying requirements is often very difficult.

 Users don’t know exactly what they want until they see it.

 Prototyping involves building a mock-up of the system and using to obtain for user feedback.

Qu ick p lan

Com m unicat ion

Mo d e lin g
Qu ick d e sig n

Deployment
De live r y Const r uct ion of
& Fe e dback pr ot ot ype

 Closely related to what are now called “Agile Methods”

 The Spiral Model

 Development cycles through multiple(3-6) task regions (6stage version).

• Customer communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Customer evaluation

 Incremental releases
- 17 -
 • Early releases may be paper or prototypes.

• Later releases become more complicated

 Models software until it is no longer used

 Not a silver bullet, but considered to be one of the best approaches.

 Is a realistic approach to the problems of large scales software development?

 Can use prototyping during any phase in the evolution of product?

 Requires excellent management and risk assessment skills

- 18 -
 Concurrent Development Model

 The concurrent development model, sometimes called concurrent engineering, can be

represented schematically as a series of framework activities, software engineering actions
and tasks, and their associated states.

 The concurrent process model defines a series of events that will trigger transitions from
state to state for each of the software engineering activities, action, or tasks.

 The concurrent process model is applicable to all types of software development and
provides an accurate picture of the current state of a project.

 Rather than confining software engineering activities, actions, and tasks to a sequence of
events, it defines a network of activities.

 Each activity, action, or task on the network exists simultaneously with other activities,
actions, or tasks.

 Events generated at one point in the process network trigger transitions among the states.

none

Modeling act ivit y

represents the state

Under of a software engineering activity or task
development

Await ing
changes

Under review

Under
revision

Baselined

Done

- 19 -
SPECIALIZED PROCESS MODELS

 Component based development—the process to apply when reuse is a development

objective.

 Formal methods—emphasizes the mathematical specification of requirements.

 AOSD—provides a process and methodological approach for defining, specifying, designing,

and constructing aspects

THE UNIFIED PROCESS (UP)

 Unified Process

 a “use-case driven, architecture-centric, iterative and incremental” software process closely

aligned with the Unified Modeling Language (UML)

- 20 -
 Unified Process Phases

 The inception phases of the up encompass both customer communication and planning
activities and emphasize the development and refinement of use-cases as a primary
model.

 An elaboration phase that encompasses the customer’s communication and modeling

activities focusing on the creation of analysis and design models with an emphasis on
class definitions and architectural representations.

 A construction phase that refines and translates the design model into implemented
software components.

 A transition phase that transfers the software from the developer to the end-user for
beta testing and acceptance.

- 21 -
  A production phase in which on-going monitoring and support are conducted.

UP Phases
Inception Elaboration ConstructionTransition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1#2 #n-1#n

 UP Work Products

 The following figure illustrates the key work products produced as consequences of the four
technical up phases.
Incept ion phase Construct ion phase
Elaboration phase
Vision document Design model
Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, Soft ware component s Int egrat ed soft ware increment
Use-case model Test plan and procedure Test cases
phases and it erat ions.
Supplement ary requirement s including non-funct
Supportional Analy sis
document model
at ion
Business model, if necessary .
Soft ware archit ect ure user manuals
One or more prot ot y pes
Descript ion. inst allat ion manuals descript ion of current increment
Execut able archit ect ural prot ot y pe.
Preliminary design model Rev ised risk list
Project plan including
it erat ion plan adapt ed workflows milest ones
t echnical work product s Preliminary user manual

- 22 -
 4. SOFTWARE REQUIREMENTS

 Contents:
 Functional and non-functional requirements
 User requirements
 System requirements
 Interface specification
 The Software Requirements Document

 Requirements engineering:

 The process of establishing the services that the customer requires from a system and the
constraints under which it operates and is developed

 The requirements themselves are the descriptions of the system services and constraints
that are generated during the requirements engineering process.

 What is a requirement?

 It may range from a high-level abstract statement of a service or of a system constraint to a

detailed mathematical functional specification
 This is inevitable as requirements may serve a dual function

- 23 -
 • May be the basis for a bid for a contract - therefore must be open to interpretation
• May be the basis for the contract itself - therefore must be defined in detail
• Both these statements may be called requirements

 Requirements abstraction (Davis, 1993)

“If a company wishes to let a contract for a large software development project, it
must define its needs in a sufficiently abstract way that a solution is not pre-defined.
The requirements must be written so that several contractors can bid for the contract,
offering, perhaps, different ways of meeting the client organisation’s needs. Once a
contract has been awarded, the contractor must write a system definition for the client
in more detail so that the client understands and can validate what the software will
do. Both of these documents may be called the requirements document for the
system.”

 Types of requirement

 User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints. Written for customers

 System requirements
• A structured document setting out detailed - descriptions of the system
services. Written as a contract between client and contractor

 Software specification
• A detailed software description which can serve as a basis for a design or
implementation. Written for developers.
 Definitions and specifications

- 24 -
  Requirements readers:

 Another classification of requirements

 Functional requirements
 Non-functional requirements
 Domain requirements

FUNCTIONAL REQUIREMENTS

 Describe functionality or system services, how the system should react to particular inputs
and how the system should behave in particular situations.
 Depend on the type of software, expected users and the type of system where the software
is used
 Functional user requirements may be high-level statements of what the system should do
but functional system requirements should describe the system services in detail.

 Examples:
• The user shall be able to search either all of the initial set of databases or select a
subset from it.
• The system shall provide appropriate viewers for the user to read documents in the
document store.
• Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be
able to copy to the account’s permanent storage area.
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways by developers and users.
 Consider the term ‘appropriate viewers’ in the previous example.
 User intention - special purpose viewer for each different document type
 Developer interpretation - Provide a text viewer that shows the contents of
the document

- 25 -
  Requirements should be complete and consistent
 Complete
 They should include descriptions of all facilities required
 Consistent
 There should be no conflicts or contradictions in the descriptions of the
system facilities

 In practice, it is impossible to produce a complete and consistent requirements document

NON-FUNCTIONAL REQUIREMENTS

 Define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.

 Can be constraints on the process too

• Use a particular CASE system, programming language or development method

 System maybe unusable if non-functional requirements are not satisfied (Critical)

 Non-functional classifications

 Product requirements
• Requirements which specify that the delivered product must behave in a particular
way e.g. execution speed, reliability, etc.

 Organisational requirements

• Requirements which are a consequence of organisational policies and procedures

e.g. process standards used, implementation requirements, etc.
 External requirements

• Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.

 Non-functional requirements examples

 Product requirement
• It shall be possible for all necessary communication between the APSE and the user
to be expressed in the standard Ada character set

 Organisational requirement
• The system development process and deliverable documents shall conform to the
process and deliverables defined in XYZCo-SP-STAN-95

- 26 -
  External requirement
• The system shall not disclose any personal information about customers apart from
their name and reference number to the operators of the system

 Goals and requirements

 Non-functional requirements may be very difficult to state precisely and imprecise

requirements may be difficult to verify.
 Goal
• A general intention of the user such as ease of use
 Verifiable non-functional requirement
• A statement using some measure that can be objectively tested
 Goals are helpful to developers as they convey the intentions of the system users

 Examples

 A system goal
• The system should be easy to use by experienced controllers and should be organised
in such a way that user errors are minimised.

 A verifiable non-functional requirement

• Experienced controllers shall be able to use all the system functions after a total of
two hours training. After this training, the average number of errors made by
experienced users shall not exceed two per day.

 Requirements measures
Property Meas ure
Speed Processed trans action s/second User/Event resp ons e time
Screen refresh time K Bytes
Number of RAM chips
Size
Trainin g time Number of help Mean time t Pro bab i
Ease of use Reliability
Rate

Rob ustn ess

Portability

 Maintainability ?

- 27 -
  Non-functional requirement conflicts

 Conflicts between different non-functional requirements are common in complex

systems
 Example: Spacecraft system
• maximum storage required should be 4MB (fit onto ROM)
• system should be written in Ada language (suitable of critical real-time software
development)
• It might be impossible to write an Ada program with the required functionality in
less than 4MB
• >> Trade-off needed.

DOMAIN REQUIREMENTS

 Derived from the application domain and describe system characteristics and features that
reflect the domain
 May be new functional requirements, constraints on existing requirements or define specific
computations
 If domain requirements are not satisfied, the system may be unworkable

 Domain requirements (examples)

 Library system
• There shall be a standard user interface to all databases which shall be based on the
Z39.50 standard.
• Because of copyright restrictions, some documents must be deleted immediately on
arrival. Depending on the user’s requirements, these documents will either be
printed locally on the system server for manually forwarding to the user or routed to
a network printer.

 Train Protection system

• The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient

Where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2
/alpha are known for different types of train

 Domain requirements problems

 Understand ability
• Requirements are expressed in the language of the application domain
• This is often not understood by software engineers developing the system

- 28 -
  Implicitness
• Domain specialists understand the area so well that they do not think of making the
domain requirements explicit.

USER REQUIREMENTS

 Should describe functional and non-functional requirements so that they are

understandable by system users who don’t have detailed technical knowledge
 User requirements are defined using natural language, tables and diagrams.

 Problems with natural language

 Lack of clarity
• Precision is difficult without making the document difficult to read
 Requirements confusion
• Functional and non-functional requirements tend to be mixed-up
 Requirements amalgamation
• Several different requirements may be expressed together
 Example: editor grid requirement

• Grid facilities To assist in the positioning of entities on a diagram, the user may turn
on a grid in either centimetres or inches, via an option on the control panel. Initially,
the grid is off. The grid may be turned on and off at any time during an editing
session and can be toggled between inches and centimetres at any time. A grid
option will be provided on the reduce-to-fit view but the number of grid lines shown
will be reduced to avoid filling the smaller diagram with grid lines.

 Requirement problems

 Grid requirement mixes three different kinds of requirement

• Conceptual functional requirement (the need for a grid)
• Non-functional requirement (grid units)
• Non-functional UI requirement (grid switching)
 Sometimes requirements include both conceptual and detailed information
• the detailed information should be specified in the system requirement specification

 Structured presentation

Grid facilities: The editor shall provide a grid facility where a matrix of horizontal
and vertical lines provides a background to the editor window. This grid shall be a
passive grid where the alignment of entities is the user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-spaced entities.
Although an active grid, where entities 'snap-to' grid lines can be useful, the positioning is
imprecise. The user is the best person to decide where entities should be positioned.

- 29 -
  Guidelines for writing requirements

 Invent a standard format and use it for all requirements

 Use language in a consistent way. Use shall for mandatory requirements, should for
desirable requirements
 Use text highlighting to identify key parts of the requirement
 Avoid the use of computer jargon
SYSTEM REQUIREMENTS

 More detailed specifications of user requirements

 Serve as a basis for designing the system
 May be used as part of the system contract

- 30 -
 System requirements may be expressed using system models

 Requirements and design

 In principle, requirements should state WHAT the system should do (and the design should
describe how it does this)
 In practice, requirements and design are inseparable
• A system architecture may be designed to structure the requirements
• The system may inter-operate with other systems that generate design requirements
• The use of a specific design may be a domain requirement

 Natural Language specification: Problems

 Ambiguity
• The readers and writers of the requirement must interpret the same words in the
same way. NL is naturally ambiguous so this is very difficult
• E.g. signs on an escalator:
• ‘Shoes must be worn’
• ‘Dogs must be carried’
 Over-flexibility
• The same thing may be said in a number of different ways in the specification
 Lack of modularisation
• NL structures are inadequate to structure system requirements

NotatAiolnternativeDs etsocrNiptLiosnpecification
Structured natural This approach depends on defining standard forms or templates to express the
language requirements specification.

Design description This approach uses a language like a programming language but with more
languages abstract features to specify the requirements by defining an operational model of
the system.

Graphical A graphical language, supplemented by text annotations is used to define the

notations functional requirements for the system. Use-case descriptions (Jacobsen,
Christerson et al., 1993) are one technique.

Mathematical These are notations based on mathematical concepts such as finite-state

specifications machines or sets. These unambiguous specifications reduce the arguments
between customer and contractor about system functionality. However, most
customers don’t understand formal specifications and are reluctant to accept it as
a system contract.

- 31 -
 Structured language specifications

 A limited form of natural language may be used to express requirements

 This removes some of the problems resulting from ambiguity and flexibility and imposes a
degree of uniformity on a specification
 Often supported using a forms-based approach

 Form-based specifications

 Definition of the function or entity

 Description of inputs and where they come from
 Description of outputs and where they go to
 Indication of other entities required
 Pre and post conditions (if appropriate)
 The side effects (if any)

 PDL-based requirements definition

 Requirements may be defined operationally using a programming language like notation but
with more flexibility of expression
 Most appropriate in two situations
• Where an operation is specified as a sequence of actions and the order is important
(when nested conditions and loops are involved)
• When hardware and software interfaces have to be specified. Allows interface
objects and types to be specified

 PDL disadvantages

 PDL may not be sufficiently expressive to express the system functionality in an

understandable way
 Notation is only understandable to people with programming language knowledge
 The requirement may be taken as a design specification rather than a model to help
understand the system

- 32 -
 Interface specification

 Most systems must operate with other systems and the operating interfaces must be
specified as part of the requirements
 Three types of interface may have to be defined
• Procedural interfaces
• Data structures that are exchanged
• Data representations
 Formal notations are an effective technique for interface specification

 PDL interface description

interface PrintServer {

// defines an abstract printer server

// requires: interface Printer, interface PrintDoc

// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;

void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ;

void cancelPrintJob (Printer p, PrintDoc d) ;

void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;

} //PrintServer

THE REQUIREMENTS DOCUMENT

 The requirements document is the official statement of what is required of the system
developers

- 33 -
 Should include both a definition and a specification of requirements
 It is NOT a design document. As far as possible, it should set of WHAT the system should do
rather than HOW it should do it

 Users of a requirements document

 Requirements document requirements!

 Specify external system behaviour

 Specify implementation constraints
 Easy to change
 Serve as reference tool for maintenance
 Record forethought about the life cycle of the system i.e. predict changes
 Characterise responses to unexpected events

 IEEE requirements standard

 Introduction
 General description
 Specific requirements

- 34 -
  Appendices
 Index
 This is a generic structure that must be instantiated for specific systems

 REQUIREMENTS DOCUMENT STRUCTURE

 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index

5. REQUIREMENTS ENGINEERING PROCESSES

 Objectives
The objective of this chapter is to discuss the activities involved in the requirements
engineering process. When you study this chapter, you will:

 Understand the principal requirements of engineering activities and their relationships;

 Have been introduced to several techniques of requirements elicitation and analysis;

 understand the importance of requirements validation and how requirements reviews are
used in this process;

 understand why requirements management is necessary and how it supports other

requirements engineering activities.

 Contents

 Feasibility studies

- 35 -
  Requirements elicitation and analysis
 Requirements validation
 Requirements management

 Requirements engineering processes

 RE processes vary widely depending on

• the application domain
• the people involved and
• the organisation developing the requirements

 However, there are a number of generic activities common to all processes

• Feasibility study
• Requirements elicitation and analysis
• Requirements specification (documenting)
• Requirements validation
• Requirements management is an additional activity to manage changing
requirements

FEASIBILITY STUDY

 A feasibility study decides whether or not the proposed system is worthwhile

 A short focused study that checks
• If the system contributes to organisational objectives
• If the system can be engineered using current technology and within budget
• If the system can be integrated with other existing systems

 Feasibility study implementation

 Based on information assessment (what is required), information collection and report

writing

- 36 -
 Questions for people in the organisation
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?

 Feasibility study report

 The FS report should recommend whether or not the system development should continue.

 It may propose changes to the scope, budget, schedule and also suggest requirement changes

REQUIREMENTS ELICITATION AND ANALYSIS

 (requirements discovery)

 Involves technical staff working with customers to find out about the application domain, the
services that the system should provide and the system’s operational constraints

 May involve end-users, managers, engineers involved in maintenance, domain experts,

trade unions, etc. These are called stakeholders

 Problems of requirements analysis

 Stakeholders don’t know what they really want

 Stakeholders express requirements in their own terms
 Different stakeholders may have conflicting requirements
 Organisational and political factors may influence the system requirements

 The requirements change during the analysis process. New stakeholders may emerge and
the business environment change

- 37 -
 The requirements analysis process

 The requirements analysis process activities

 Domain understanding
 Requirements collection
 Classification
 Conflict resolution
 Prioritisation
 Requirements checking

 Techniques for requirement elicitation and analysis

 viewpoint-oriented elicitation
 ethnography
 scenarios
 structured analysis methods (system models)
 prototyping
 There is no universal method for requirement analysis!

 System models

 Different models may be produced during the requirements analysis activity

 Will be covered later

 Viewpoint-oriented elicitation

- 38 -
 Stakeholders represent different ways of looking at a problem or problem viewpoints
 This multi-perspective analysis is important as there is no single correct way to analyse
system requirements

 Scenarios

 Descriptions of how a system is used in practice

 Helpful in requirements elicitation as people can relate to these more easily than an abstract
statement of what they require from a system
 Useful for adding detail to an outline requirements description

 Scenario descriptions

 System state at the beginning of the scenario

 Normal flow of events in the scenario
 What can go wrong and how this is handled
 Other concurrent activities
 System state on completion of the scenario

 Scenario based techniques

 use cases!
 event scenarios
• Event scenarios may be used to describe how a system responds to the occurrence
of some particular event
• Used in the Viewpoint Oriented Requirements Definition (VORD) method.

 Ethnography

 An analyst spends time observing and analysing how people actually work
 People do not have to explain their work
 Social and organisational factors of importance may be observed
 Identifies implicit system requirements
 Ethnographic studies have shown that work is usually richer and more complex than
suggested by simple system models

 Scope of ethnography

 Requirements that are derived from the way that people actually work rather than the way
in which process definitions suggest that they ought to work
• e.g. air-traffic controllers switch off flight path conflict alarms

- 39 -
  Requirements that are derived from cooperation and awareness of other people’s activities
• e.g. predict no. of aircraft entering their sector by getting information from
neighbouring controllers and plan accordingly

 Not suitable for using alone, has to be combined with some other technique

REQUIREMENTS VALIDATION

 Concerned with showing that the requirements define the system that the customer really
wants
 Requirements error costs are high so validation is very important
• Fixing a requirements error after delivery may cost up to 100 times the cost of fixing
an implementation error

 Types of requirements checking

 Validity. Does the system provide the functions which best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the customer included?
 Realism. Can the requirements be implemented given available budget and technology
 Verifiability. Can the requirements be checked

 Requirements validation techniques

 Requirements reviews
• Systematic manual analysis of the requirements
 Prototyping
• Using an executable model of the system to check requirements.
 Test-case generation
• Developing tests for requirements to check testability
 Automated consistency analysis
• Checking the consistency of a structured requirements description

 Requirements reviews

 Regular reviews while the requirements definition is being formulated

 Both client and contractor staff should be involved in reviews
 Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage

 Review checks

- 40 -
  Verifiability. Is the requirement realistically testable?
 Comprehensibility. Is the requirement properly understood?
 Traceability. Is the origin of the requirement clearly stated?
 Adaptability. Can the requirement be changed without a large impact on other requirements?

 Automated consistency checking

REQUIREMENTS MANAGEMENT

 Requirements management is the process of managing changing requirements during the

requirements engineering process and system development
 Requirements are inevitably incomplete and inconsistent
• New requirements emerge during the process as business needs change and a
better understanding of the system is developed
• Different viewpoints have different requirements and these are often contradictory

 Why requirements change

 The priority of requirements from different viewpoints changes during the development
process
 System customers may specify requirements from a business perspective that conflict
with end-user requirements
 The business and technical environment of the system changes during its development

 Requirements evolution

- 41 -
 Enduring and volatile requirements

 Enduring requirements. Stable requirements derived from the core activity of the
customer organisation.
• May be derived from domain models
• E.g. a hospital will always have doctors, nurses, etc.

 Volatile requirements. Requirements which change during development or when the

system is in use.
• E.g. In a hospital, requirements derived from health-care policy

 Classification of volatile requirements

 Mutable requirements
• Requirements that change due to the system’s environment
 Emergent requirements
• Requirements that emerge as understanding of the system develops
 Consequential requirements
• Requirements that result from the introduction of the computer system
 Compatibility requirements
• Requirements that depend on other systems or organisational processes

 Requirements management planning

 During the requirements engineering process, you have to plan:

• Requirements identification
• How requirements are individually identified
• A change management process
• The process followed when analysing a requirements change
• Traceability policies
• The amount of information about requirements relationships that is
maintained
• CASE tool support

- 42 -
 • The tool support required to help manage requirements change

 Traceability

 Traceability is concerned with the relationships between requirements, their sources and
the system design
 Source traceability
• Links from requirements to stakeholders who proposed these requirements
 Requirements traceability
• Links between dependent requirements
 Design traceability
• Links from the requirements to the design

 A traceability matrix

Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 D R

1.2 D R D

1.3 R R

2.1 R D D

2.2 D

2.3 R D

3.1 R

3.2 R

 CASE tool support

 Requirements storage
• Requirements should be managed in a secure, managed data store
• We need requirement databases!
 Change management
• The process of change management is a workflow process whose stages can be
defined and information flow between these stages partially automated
 Traceability management
• Automated retrieval of the links between requirements

- 43 -
 Requirements change management

 Should apply to all proposed changes to the requirements

 Principal stages
• Problem analysis. Discuss requirements problem and propose change
• Change analysis and costing. Assess effects of change on other requirements
• Change implementation. Modify requirements document and other documents to
reflect change

6. SYSTEM MODELS

 Objectives

The objective of this chapter is to introduce a number of system models that may be
developed during the requirements engineering process. When you have study the chapter,
you will:

 Understand why its is important to establish the boundaries of a system and model its
context;
 Understand the concepts of behavioural modeling, data modeling and object modeling;
 Have been introduced to some of the notations defined in the Unified Modeling Language
(UML) and how these notations may be used to develop system models.

 Contents

 Context models
 Behavioural models

- 44 -
  Data models
 Object models
 Structured methods

 System models

 Abstract descriptions of systems whose requirements are being analysed

• used to develop an understanding of the existing system or to specify the required
system
• used to communicate with others
• they simplify the system (by leaving out details) and emphasise certain characteristics

 Different perspectives

 Different models present the system from different perspectives

• External perspective - showing the system’s context or environment

• Behavioural perspective - showing the behaviour of the system
• Structural perspective - showing the system or data architecture

 Model types

 (Different approaches to abstraction)

 Data flow model showing how the data is processed at different stages.

 Composition model showing how entities are composed of other entities.

 Architectural model showing principal sub-systems.

 Classification model showing how entities have common characteristics.

 Stimulus/response model showing the system’s reaction to events.

CONTEXT MODELS

 Used to illustrate the operational context of a system - show what lies outside the system
boundaries.

 Not only technical factors affect system boundary positioning

- 45 -
 • Social and organisational concerns

 Architectural models show the system and its relationship with other systems.