NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

UNIT-II
REQUIREMENTS ANALYSIS AND SPECIFICATION

2.1 SOFTWARE REQUIREMENTS

 Requirements of a system are the descriptions of the services provided by the system and
its operational constraints.
 The requirements reflect the needs of customers for a system that helps solve the problem
 Requirements specify what the system is supposed to do but not how the system is to
accomplish the task.
 Requirements should be precise, complete, and consistent
 Precise - They should state exactly what is desired of the system

 Complete - They should include descriptions of all facilities required
 Consistent - There should be no conflicts in the descriptions o f the system
facilities
 Requirement analysis
 specifies soft war e’ s operational charact eri stics
 indicates software's interface with other system elements

 establishes constraints that software must meet

 Requirements analysis allows the software engineer to:
 elaborate on basic requirements established during earlier requirement
engineering tasks
 Build models that depict user scenarios, functional activities, problem classes and
their relationships, system and class behavior, and the flow of data as it is
transformed.
 Requirement can be
 Functional
 Non-functional
 Domain

1
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

2.1.1 FUNCTIONAL REQUIREMENTS

 Functional requirements describe the services provided by the system, how the system
should react to particular inputs and how the system should behave in particular
situations.
 The functional requirements may also explicitly state what the system should not do.
 They depend on the type of the system being developed, expected user of the system and
approach used for writing the requirements.
 Eg:
 Compute the transactions (deposit, withdraw, print report etc) in a bank ATM
system
 Compute the salary of the employee in a payroll processing syste m etc
 The functional requirements specification of a system should be both complete and
consistent. Completeness means that all services required by the user shou ld be defined.
Consistency means that requirements should not have contradictory definitions.

2.1.2 NON-FUNCTIONAL REQUIREMENTS

 Non f unctional requirements are the constraints on the services offered b sy the system
such atiming constraints, constraints on the development process, standard s, etc.

 Non functional requirements are not directly concerned with specific functions delivered
by the system.

 They specify system performance, security, availability, and other emergent properties.
Types of non-functional requirements:
1. Product requirements:
 These requirements specify the product behavior.
 Ex: execution speed, memory requirement, reliability requirements that set out the
acceptable failure rate; portability requirements; and usability requirements etc
2. Organisational requirements
 These requirements are derived from policies and procedures of the organization.

2
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Ex: process standards that must be used; implementation requirements such as the
programming language or design method used and delivery requirements that specify
when the product and its documentation are to be delivered.
No n-fu nct io nal
requ ir ement s

Pro du ct Or g an izat io nal Ex tern al

requ ir ement s requ ir ement s requ irement s

Ef fici ency Reli ab il it y Po rt abil it y Int ero perab il it y Et hi cal

requ ir ement s requ ir ement s requ irement s requ irement s requ irement s

Us ab il it y Del ivery Impl ement at io n St and ard s Leg is lat ive

requ irement s requ irement s requ ir ement s requ irement s requ irement s

Perfo rmance Sp ace Priv acy requ Safety

requ irement s ir ement s requ irement s requ irement s

Fig: Non- functional requirements

3. Exter nal requirements
 These requirements are derived from factors external to the sys tem and its
development process.
 Eg: interoperability requirements that define how the system interacts with syst ems in
other organizations.
 Non functional requirements are more critical than individual functional requirements. if
these are not met, the system is useless
 Eg: if an aircraft system does not meet its reliability requirement, it will not be certified
as safe for operation. If a real time control system fails to meet performance requirement,
the control functions will not operate properly.
 Problem with non functional requirements is that they are difficult to verify.
 Non-functional requirements often conflict and interact with other functional or non-
functional requirements.
 It’s better to differentiate functional and non-functional requirements in the requirements
document. But it’s difficult to do so.

3
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Metrics used to specify the non functional requirements are:

Fig: Metrics for specifying non- functional requirements

 If the non-functional requirements are stated separately from the functional requirements,
it is sometimes difficult to see the relationships between them.
 If the y are stated with the functional requirements, then it may be difficult to separate
functional and nonfunctional considerations and to identify requirements that relate to the
system as a whole
 So the requirements that are clearly related to emergent system prope rties, such as
performance or reliability can be explicitly highlighted by putting them n in a separate
sectioof the requirements document or distinguishing them from other system
requirements
Domain requirements
 These requirements come from the application domain of the system.
 They reflect the characteristics and constraints of that domain
 They may be new functional requirement or non functional requirementss) or set out how
particular computations must be carried out
 Eg: LIBSYS
 There shall be a standard user interface to all databases that shall be based on the
Z39.50 standards.  This is a design constraint. So the developer has to find
out about the standard before starting the interface design.
 The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient

4
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 This uses a domain specific terminology. To understand this you need

understanding of operation of railway system and train characteristics
 Drawback: domain requirements are written in the language of application domain which
is difficult for the software engineer to understand.

2.1.3 USER RQUIREMENTS

 User requirements describe what services the system is expected to provide and the
constraints under which it must operate.
 These requirements should describe functional and non-functional requirements so that
they are understandable by system users who don’t have detailed technical knowledge
 They should specify only the external behaviour and avoid the sy stem design
characteristics
 User r equirements are defined using natural language, tables, and diagrams
 Proble ms faced with natural language:
 Lack of clarity: It is sometimes difficult to use language in a precise and
unambiguous way without making the document wordy and difficult to r ead.
 Requirements confusion: Functional requirements, non-functional requirements,
system goals and design information may not be clearly distinguished.
 Requirements amalgamation: Several different requirements may be expressed
together as a single requirement.
 This r equirement includes both conceptual and detailed information.
 The user requirement should simply focus on the key facilities to be provided.
 A rationale can be associated with each user requirement which explains why the
requirement has been included and is particularly useful when requirements are changed
 Guidelines to be followed to minimize misunderstandings when writing user
requirements:
 Use a standard format to define all the requirement.
 Use language consistently.
 Use text highlighting (bold, italic or color) to pick out key parts of the
requirement.
 Avoid using computer jargon /technical terms

5
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

2.1.4 SYSTEM REQUIREMENTS

 System requirements describe the external behavior of the system and its operational
constraints.
 This explains how the user requirements should be provided by the system
 System requirement should be a complete and consistent specification of the whole
system
 Natural language is often used to write system requirements specifications
 Drawbacks of using natural language specifications for specifying system requirements:
1. Natural language understanding relies on the specification readers and writers using
the same words for the same concept. This leads to misunderstandings because of the
ambiguity of natural language.
2. A natural language requirements specification is over flexible.
3. It is difficult to modularize natural language requirements. It may be difficult to find
all related requirements.
Notations used for System requirements specification
 Struc tured natural language
 This approach depends on defining standard forms or templates t o express the
requirements specification.
 Desi gn description languages
 This approach uses a language like a programming language bu t with more
abstract feature to specify the requirements by defining an operatio nal model of
the system
 Graphical notations
 A graphical language, supplemented by text annotations is used to define the
functional requirements for the system. Eg: SADT(structured analysis and design
techniques), use case diagram, sequence diagrams etc
 Mathematical specifications
 These are notations based on mathematical concepts such as finite-state machines
or sets. These unambiguous specifications reduce the arguments between
customer and contractor about system functionality

6
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

Structured natural language specifications

 Structured natural language is a way of writing system requirements in a standard format.
 Advantage of this approach is that it maintains most of the expressiveness and
understandability of natural language but ensures that some degree of uniformity is
imposed on the specification.
 Structured language notations limit the terminology that can be used and use templates to
specify system requirements.
 They may include control constructs derived from programming languages and graphical
highlighting to partition the specification.
 When a standard form is used for specifying functional requirements, the following
information should be included:
1. Description of the function or entity being specified
2. Description of its inputs and where these come from
3. Description of its outputs and where these go to
4. Indication of what other entities are used (the requires part)
5. Description of the action to be taken
6. If a functional approach is used, a pre-condition setting out what must be true
before the function is called and a post-condition specifying what is true after the
function is called
7. Description of the side effects (if any) of the operation.
Advantages:
 Variability in the specification is reduced and requirements are organized more
effectively.
 To avoid ambiguity, add extra information to natural language requirements using tables
or graphical models of the system. These can show how computations proceed, how the
system state changes, how users interact with the system and how sequences of actions
are performed.

7
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Eg : To compute the insulin dose for a person

Fig: system requirements to compute the insulin dosage for a person

 Table s are useful when there are a number of possible alternative situations and actions
to be taken.
 Eg:

Fig: sample table for system requirement specification

8
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Graphical models are most useful to show how state changes and to describe a sequence
of actions
 Eg: sequence diagram for ATM withdrawal

Fig: Sequence diagram for withdraw()

2.2 REQUIREMENTS ENGINEERING

 Requirements engineering (RE) is the process of identifying, analyzing, documenting and

checking the services and constraints.
 Requirements engineering process is to create and maintain a system requirements
document.
 Requirements engineering includes the task and techniques used to understand the basic
requirements of the system.

9
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Process involved in Requirements engineering:

Feasi bi li ty Requ irement s
s tu dy eli cit ati on an d
analy si s
Requ ir ement s
s pecifi cati on
Feasi bi li ty Requ irement s
repo rt v al id ati on
Sy st em
mo dels
Us er an d s ys tem
requ iremen ts

Requ irement s
d ocumen t

Fig: Requirements Engineering Process

1. Fe asibility Study- concerned with assessing whether the system is useful to the
business
2. R equirements elicitation and analysis - discovering requirements
3. R equirements specification - converting these requirements into s ome standard
form
4. R equirements Validation - checking that the requirements actually define the
system that the customer wants.
 The re quirements engineering process is an iterative process around a spiral.

Fig: Requirements Engineering

10
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 The amount of time and effort for each activity in the iteration depends on the stage of
the overall process and the type of system being developed.
 Early stage includes understanding the non-functional requirements and the user
requirements. Later stages are devoted to system requirements engineering and system
modeling.
 The number of iterations around the spiral can vary
 Requirements engineering is the process of applying a structured analysis method such as
object-oriented analysis
 This involves analyzing the system and developing a set of graphical system models,
such as use-case models, that then serve as a system specification.
2.2.1 FEASIBILITY STUDY
 Feasib ility study is used to determine if the user needs can be satisfied with the available
technology and budget
 Feasib ility study checks the following:
Does the system contribute to organisational objectives?

 Can the system can be implemented using current technology and within budget
Can the system can be integrated with other systems that are used

 If a system does not support these objectives, it has no real value to the business.
 Feasibility study is based on the information assessment, information c ollection and
report writing.
 Sample Questions that may be asked for information collection are:
1. What if the system wasn’t implemented?
2. What are current process problems?
3. How will the proposed system help?
4. What will be the integration problems?
5. Is new technology needed? What skills?
6. What facilities must be supported by the proposed system?
 Information sources are the managers of the departments, software engineers, technology
experts and end-users of the system.
 The feasibility study should be completed in two or three weeks.
 After collecting the information, the feasibility report is created.

11
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 In the report, changes to the scope, budget and schedule of the system can be proposed
and also suggest further high-level requirements for the system.
1.2.2 REQUIREMENTS ELICITATION AND ANALYSIS
 Requirements elicitation is nothing but identifying the application domain, the services
that the system should provide and the constraints.
 Requirements are gathered from the stakeholders
 Stakeholders are any person or group who will be affected by the system, directly or
indirectly. Eg: end-users, managers, engineers, domain experts etc
 Drawbacks of Eliciting and understanding stakeholder requirements:
1. Stakeholders don’t know what they really want.
2. Stakeholders express requirements in their own terms.
3. Different stakeholders may have conflicting requirements.
4. Organisational and political factors may influence the system requirements.
5. The requirements change during the analysis process. New stak eholders may
emerge and the business environment change.
Steps involved in requirements elicitation and analysis
1. Requ irements discovery
This is the process of interacting with stakeholders in the system t o collect their
requirements. Domain requirements are also identified.
2. Requ irements classification and organisation
This activity takes the unstructured collection of requirements, g roups related
requirements and organises them into coherent clusters.
3. Requirements prioritisation and negotiation
Since multiple stakeholders are involved, requirements will conflict. This activity
is concerned with prioritizing the requirements, and finding and resolving requirements
conflicts through negotiation.
4. Requirements documentation
The requirements are documented and input into the next round of the spiral for
further requirements discovery. Formal or informal requirements documents may be
produced.

12
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

Re quir e me n t s Re quir e me n t s
c la ssif ic at io n an d p r ior i t iz at i on and
o r ga n isat ion n ego t ia t ion

Re quir e me n t s Re quir eme n t s

disc ov e r y doc um en t at ion

Fig: Requirement Elicitation and Analysis

Requirements discovery
 Requirements discovery is the process of gathering information about the proposed and
existing systems and distilling the user and system requirements from this in formation.
 Sources of information during the requirements discovery phase include d m
ocumentation,
systestakeholders and specifications of similar systems.
 Stake holders are interacted through interviews and observation, and may use scenarios
and prototypes to help with the requirements discovery.
 Stake holders range from system end-users through managers and external stakeholders
such as regulators who certify the acceptability of the system.
 For example,
System stakeholders for a bank ATM include:
Current bank customers, Representatives from other banks, Managers of bank
branches, Counter staff at bank branches, Database administrators, Bank security
managers, bank's marketing department, Hardware and software maintenance engineers,
National banking regulators etc
 The requirements may also come from the application domain and from other systems
that interact with the system being specified.

13
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 These requirements sources (stakeholders, domain, systems) can all be represented as

system viewpoints
 Each viewpoint presents a sub-set of the requirements for the system. Each viewpoint
provides a fresh perspective on the system, but these perspectives are not completely
independent--they usually overlap so that they have common requirements.
Viewpoints
 Viewpoint-oriented approach recognizes multiple perspectives of the stakeholders and
provides a framework for discovering conflicts in the requirements proposed by different
stakeholders.
 Types of viewpoint:
1. In teractor viewpoints
 This viewpoint represents people or other systems that interact directly with
the system.Eg: In bank ATM system, the interactor viewpoints are the bank's
customers and the bank's account database.
 Interactor viewpoints provide detailed system requirements covering the
system features and interfaces.
2. I direct viewpoints
 This represents the views of stakeholders who do not use the system
themselves but who influence the requirements in some way.
 Eg: In the bank ATM system, the indirect viewpoints are the m anagement of
the bank and the bank security staff.
 Indirect viewpoints are more likely to provide higher-level organisational
requirements and constraints
3. Domain viewpoints
 This represents the domain characteristics and constraints that influence the
system requirements.
 Eg: In the bank ATM system, the domain viewpoint would be the standards that
have been developed for interbank communications.
 Domain viewpoints normally provide domain constraints that apply to the system

14
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Almost all organisational systems must interoperate with other systems in the
organisation. When a new system is planned, the interactions with other systems must be
planned which may place requirements and constraints on the new system.
 Finally organise and structure the viewpoints into a hierarchy.
 Eg: viewpoint hierarchy for LIBSYS

 Once viewpoints have been identified and structured, identify the most important
viewpoints and start with them to discover the system requirements.
Interviewing
 RE te am asks questions to stakeholders about the system they are using and the system to
be developed and derive the requirements from their answers.
 Interv iews may be of two types:
1. Clo sed interviews where the stakeholder answers a predefined set of questions.
2. Op en interviews where there is no predefined agenda and a range of issues are
explored with stakeholders.
 Completely open-ended discussions rarely work well; most interviews require some
questions to get started and to keep the interview focused on the system to be developed.
 Interviews are good for getting an overall understanding of what stakeholders do, how
they might interact with the system and the difficulties that they face with current
systems.
 Interviews are not good for understanding the domain requirements
 Interviews are not an effective technique for eliciting knowledge about organisational
requirements and constraints
 It is hard to elicit domain knowledge during interviews for two reasons:
o Requirements engineers cannot understand specific domain specific terminology;

15
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

o Some domain knowledge is so familiar that people find to explain or they think it
is so fundamental that it isn't worth mentioning.
Scenarios
 Scenarios are real-life examples of how a system can be used.
 Scenarios are useful for adding detail to an outline requirements description. They are
descriptions of example interaction sessions.
 Each scenario covers one or more possible interactions.
 The scenario starts with an outline of the interaction, and, during elicitation, details are
added to create a complete description of that interaction.
 Scenarios should include
o A description of the starting situation;
o A description of the normal flow of events;
o A description of what can go wrong and how it is handled;
o Information about other concurrent activities;
o A description of the state when the scenario finishes.
 Scena rios may be written as text, diagrams, screen shots etc
 Alternatively, a more structured approach such as event scenarios or use cases may be
adopted
Use cases
 Use-c ases are a scenario based technique in the UML (Unified Modellin g Language)
notation for describing object oriented system model.
 Use cases identify the actors involved and the type of interaction between them.
 Eg:

Fig: Use case diagram for article printing

16
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 A set of use cases should describe all possible interactions with the system.
 Actors in the process are represented as stick figures, and each class of interaction is
represented as a named ellipse.
Sequence diagrams
 Sequence diagrams are used to add detail to use-cases by showing the sequence of event
processing in the system.
 Eg:

Fig: Sequence diagram for withdraw from ATM

Ethnography
 Ethnography is an observational technique that can be used to understand social and
organisational requirements.
 Ethnography helps analysts to discover implicit system requirements that reflect the
actual rather than the formal processes in which people are involved.
 Ethnography is particularly effective at discovering two types of requirements:
o 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.
o Requirements that are derived from cooperation and awareness of other people’s
activities

17
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Ethnography may be combined with prototyping.

Fig: Ethnography process

 The ethnography informs the development of the prototype so that fewer prototype
refinement cycles are required.
 Furthe rmore, the prototyping focuses the ethnography by identifying problems and
questions that can then be discussed with the ethnographer.
 Ethno graphic studies can reveal critical process details that are often mi ssed by other
requirements elicitation techniques.
 This a pproach is not appropriate for discovering organisational or domain requirements
as it focuses on the end users.

2.2.3 SOFTWARE REQUIREMENTS DOCUMENT/ SOFTWARE SPECIFICATION

 Also r eferred as software requirements specification or SRS
 The s oftware requirements document is the official statement of what the system
developers should implement.
 It should include both the user requirements for a system and a detailed specification of
the system requirements.
 The user and system requirements may be integrated into a single description.
 The user requirements are defined in an introduction to the system requirements
specification.
 If there are a large number of requirements, the detailed system requirements may be
presented in a separate document.

18
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Users of the requirements document are:

Fig: Users of SRS

 Requirements document helps in communicating the requirements to customers, defining
the re quirements in detail for developers and testers, and including infor mation about
possible system evolution.
 Requirements information can help system designers to avoid restrictive design decisions
and help system maintenance engineers who have to adapt the system to new
requirements.
 The le vel of detail to be included in a requirements document depends o n the type of
system that is being developed and the development process used.
 When the system will be developed by an external contractor, the system specifications
need to be precise and very detailed.
 When there is more flexibility in the requirements and an iterative development process
is used, the requirements document can be much less detailed
 IEEE standard suggests the following structure for requirements documents:
1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations

19
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements cover functional, non functional and interface
requirements.
The requirements may document external interfaces, desc ribe system
functionality and performance, specify logical database requirements, design
constraints, emergent system properties and quality characteristics.
4. Appendices
5. Index
 It is a general framework that can be tailored and adapted to define a st andard to the
needs of a particular organization
 Requirements documents are essential when an outside contractor is de veloping the
software system.
 The focus will be on defining the user requirements and high-level, non-functional
system requirements.
 When the software is part of a large system engineering project that includes interacting
hardware and software systems, it is essential to define the requirements to a fine level of
detail.
2.2.4 REQUIREMENTS VALIDATION
 Requirements validation is concerned with showing that the requirements actually define
the system that the customer wants.
 Requirements error costs are high so validation is very important
 When the requirements change that the system design and implementation must also be
changed and then the system must be tested again. So the cost of fixing a requirement
problem is greater than repairing the design or coding errors

20
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Requirements checking:
1. Validity checks
 A user needs the system to perform certain functions.
 Does the system provide the functions which best support the customer’s
needs?
2. Consistency checks
 Are there any requirements conflicts?
3. Completeness checks
 The requirements document should include requirements, which define all
functions, and constraints intended by the system user.
 Are all functions required by the customer included?
4. Realism checks
 Can the requirements be implemented given available budget and technology?
5. Verifiability
 To reduce the potential for dispute between customer and contr actor, system
requirements should always be written so that they are verifiable.
 Can the requirements be checked?
Requirements validation techniques
1. Requ irements reviews
The requirements are analysed systematically by a team of reviewers.
2. Protot yping
An executable model of the system is demonstrated to end-users and customers to see
if it meets their real needs
3. Test-case generation
Requirements should be testable. This approach is for developing tests for
requirements to check testability.
If the tests for the requirements are devised as part of the validation process, this often
reveals requirements problems. If a test is difficult or impossible to design, then the
requirements will be difficult to implement and should be reconsidered.

21
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

Requirements reviews
 A requirements review is a manual process that involves people from both client and
contractor organisations to check the requirements document for anomalies and
omissions.
 Requirements reviews can be informal or formal.
 Informal reviews involve contractors discussing requirements with the system
stakeholders. Good communications can help to resolve problems at an early stage.
 In a formal requirements review, the development team explains the implications of each
requirement to the client. The review team should check each requirement for
consistency as well as completeness.
 Reviewers may also check for:
1. Verifiability. Is the requirement realistically testable?
2. Comprehensibility. Is the requirement properly understood?
3. Traceability. Is the origin of the requirement clearly stated? Traceability is important
as it allows the impact of change on the rest of the system to be assessed
4. Adaptability. Can the requirement be changed without a large impact on other
requirements?
 Conflicts, contradictions, errors and omissions in the requirements should be pointed out
by reviewers and formally recorded in the review report.
 It is then up to the users, the system procurer and the system developer to negotiate a
solution to these identified problems.
1.3 REQUIREMENTS MANAGEMENT
 Requirements management is the process of managing changing requirements during the
requirements engineering process and system development.
 Requirements management is the process of understanding and controlling changes to
system requirements.
 Requirements are incomplete and inconsistent because:
o New requirements arise during the process as business needs change and a better
understanding of the system is developed;
o Different viewpoints have different requirements and these are often
contradictory.

22
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Requirements may change over time for the following reasons:

 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.
Types of requirements:
 Enduring requirements.
These are stable requirements derived from the core activity of the customer
organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from
domain models
 Volatile requirements.
These are requirements which change during development or when the system is
in use. In a hospital, requirements derived from health-care policy

Fig: Requirement Evolution

 Mutable requirements
Requirements that change because of changes to the environment in which the
organisation is operating. For example, in hospital systems, the funding of patient care
may change and thus require different treatment information to be collected.
 Emergent requirements
Requirements that emerge as the customer's understanding of the system develops
during the system development. The design process may reveal new emergent
requirements

23
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Consequential requirements
Requirements that result from the introduction of the computer system.
Introducing the computer system may change the organisations processes and open up
new ways of working which generate new system requirements
 Compatibility requirements
Requirements that depend on the particular systems or business processes within
an organisation. As these change, the compatibility requirements on the commissioned or
delivered system may also have to evolve.
Requirements management planning:
 During the requirements engineering process, you have to plan:
o Requirements identification
 Each requirement must be uniquely identified so that it can be cross-
referenced by other requirements and so that it may be used in traceability
assessments.
o A change management process
 This is the set of activities that assess the impact and cost of changes
o Traceability policies
 These policies define the relationships between requirements, and between
the requirements and the system design that should be recorded and how
these records should be maintained.
o CASE tool support
 The tool support required to help manage requirements change;
Traceability
 Traceability is concerned with the relationships between requirements, their sources and
the system design
 Types of traceability information:
o Source traceability
 Links from requirements to stakeholders who proposed these
requirements;
o Requirements traceability
 Links between dependent requirements;

24
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 This information helps to assess how many requirements are likely to be

affected by a proposed change
o Design traceability
 Links from the requirements to the design;
 This information helps to assess the impact of proposed requirements
changes on the system design and implementation.
 Fig: Traceability Matrix

CASE tools support for:

 Requirements storage
o Requirements should be managed in a secure, managed data store.
 Chang e management
o The process of change management is simplified using CASE tools.
 Traceability management
o Tools help to discover possible relationship between the requirements.
2.4 REQUIREMENTS CHANGE MANAGEMENT
 Requirements change management should be applied to all proposed changes to the
requirements
 Stages
o Problem analysis. Identifying the requirements problem and propose change;
o Change analysis and costing. Assess effects of change on other requirements
and estimate the cost of the impact using the traceability information

25
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

o Change implementation. Modify requirements document and other documents

to reflect change
Fig: Requirements change management process

Requirement problem

Problem Analysis & change

specification

Change Analysis and costing

Change Implementation

Incorporated changes in the requirements

2.5 SYSTEM MODELING

2.5.1 STRUCTURED SYSTEM ANALYSIS
 Syste m models are graphical representations that describe business p rocesses, the
problem to be solved and the system that is to be developed.
 Grap hical representations are often more understandable than detailed natural language
descriptions of the system requirements
 Different models present the system from different perspectives
o External perspective showing the system’s context or environment
o Behavioural perspective showing the behaviour of the system
o Structural perspective showing the system or data architecture
Types of analysis models:
 Structured analysis
 Object-oriented analysis
Three primary objectives of the analysis model:
 to describe what the customer requires

26
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 to establish a base for the creation of a software design

 to define a set of requirements that can be validated
Elements of Analysis model:
 The core - data dictionary
- this contains the descriptions of all data objects in the software
 The entity-relationship diagram (ERD)
- ERD specifies the attributes of data objects and also depicts the relationships
between data objects.
 The data flow diagram (DFD)
- DFD provides an indication of how data are transformed as they move through
the system.
- DFD depicts the functions that transform the data flow.
 The st ate-transition diagram(STD)
-This indicate how the system behaves as a consequence of external events

DATA MODELLING:
 Entity-Relationship Diagram is a very useful method for data modeling.
 It repr esents:
o data objects, object attributes, and relationships between objects
 Eg:

27
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

PROCESS MODELLING
 Process model represents the system’s function.
 This graphically represent the process that capture, manipulate, store and distribute data
between the system and its environment
 Eg: Data Flow Diagram
DATA FLOW DIAGRAM
 A Data Flow Diagram (DFD) is a graphical representation of the flow of data through an
information system, modeling its process aspects.
 This is used to create an overview of the system
Elements of DFD:
 external entity - people or organisations that send data into the system or receive data
from t he system
 proce ss - models what happens to the data i.e. transforms incoming data into outgoing
data
 data s tore - represents permanent data that is used by the system
 data f low - models the actual flow of the data between the other elements

Fig: Symbols used in DFD

DFD Diagramming rules:
 Data flow can take place between processes from
o data store to a process and a process to a data store
o external entity to a process and from process to an external entity
 Data flows can’t take place between 2 data stores or two external entities
 Data flows are unidirectional
 A process must have at least one input and one output

28
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

Developing DFDs
 Context diagram is an overview of an organizational system that shows:
o The system boundaries.
o External entities that interact with the system.
o Major information flows between the entities and the system.
 Note: only one process symbol, and no data stores shown
Eg:

Fig: Context level DFD for course registration system

 Level-1 diagram is a data flow diagram that represents a syst em’ s maj or processes, data
flows, and data stores at a high level of detail.

Fig: Level – 1 DFD

29
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Level-n Diagram shows how the system is divided into sub-systems (processes), each of
which deals with one or more of the data flows to or from an external agent, and which
together provide all of the functionality of the system as a whole.
 Eg:

Fig: level 2 DFD for Process 1: Register student for the course

Class Diagram
 A cla ss is a collection of objects with common structure, common behav ior, common
relationships and common semantics
 Classes are found by examining the objects in sequence and collaboration diagram
 A class is drawn as a rectangle with three compartments
 A class diagram shows the existence of classes and their relationships in the logical view
of a system
 UML modeling elements in class diagrams
 Classes and their structure and behavior
 Association, aggregation, dependency, and inheritance relationships
 Multiplicity and navigation indicators
 Role names

30
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Eg: ATM system

Fig: Class diagram for ATM System

2.5.2 PETRI NETS
 A Pet ri net is also known as a place/transition net
 It is a diagrammatic tool to model concurrency and synchronization in distributed
systems.
 It is si milar to State Transition Diagrams.
 This is used as a visual communication aid to model the system behaviour.
 This is a mathematical modeling language for the description of distributed systems
 Petri n ets can be used to model complex processes
 Petri nets can be simulated in order to illustrate and test system behaviour, benchmark its
speed etc.
Components:
 Places (circles): Places represent possible states of the system;
 Transitions (rectangles): events or actions which cause the change of state;
 Arcs (arrows): Used to connect a place with a transition or a transition with a place.
 Change of state is denoted by a movement of tokens (black dots) from place to place and
is caused by the firing of a transition.
 The firing represents an occurrence of the event or an action taken.
 The firing is subject to the input conditions, denoted by token availability.

31
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 A transition is firable or enabled when there are sufficient tokens in its input places.
 After firing, tokens will be transferred from the input places (old state) to the output
places, denoting the new state.
 Eg: firing event

Primitive str ctures that occur in real systems:

32
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

2.3 DATA DICTIONARIES

 Data dictionaries are lists of all of the names used in the system models. Descriptions of
the entities, relationships and attributes are also included
 Collects and coordinates data terms, and confirms what each term means to different
people in the organization
 Many CASE workbenches support data dictionaries
 The data dictionary may be used for the following reasons:
 Provide documentation
 Eliminate redundancy
 Validate the data flow diagram
 Provide a starting point for developing screens and reports

 To develop the logic for DFD processes

 Data d ictionaries contain
 Data flow

 Data structures

 Elements

 Data stores

Defining Data Flow
 Each data flow should be defined with descriptive information and it's composite
structure or elements
Eg:

Fig: Data flow definition for customer order

 Include the following information:
 ID - identification number

33
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 Label, the text that should appear on the diagram

 A general description of the data flow
 The source and destination of the data flow
 Type of data flow
 The name of the data structure describing the elements
 The volume per unit time
 An area for further comments and notations
Defining Data Structures
Data structures are a group of smaller structures and elements
An algebraic notation is used to represent the data structure
 The symbols used are
 Equal sign, meaning “consi st s of ”
 Plus sign, meaning "and”
 Braces {} meaning repetitive elements, a repeating element or group of elements
 Brackets [] for an either/or situation- The elements listed inside are mutually
exclusive
 Parentheses () for an optional element

 A rep eating group may be
 A sub-form

 A screen or form table

 A program table, matrix, or array

 There may be one repeating element or several within the group
 Data structure may be logical or physical data structure
o Logical: Show what data the business needs for its day-to-day operations
o Physical: Include additional elements necessary for implementing the system
Eg: Data structure for customer details
Customer name = First name + (middle name) + last name
Address= Street + (Apartment) + City + State +Zip
Data Element
Data element includes the following:
 Element ID

34
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 The name of the element

 Aliases -Synonyms or other names for the element
 A short description of the element
• Element is base or derived
• A base element is one that has been initially keyed into the system
• A derived element is one that is created by a process, usually as the result
of a calculation or a series of decision-making statements
 Element length
 Type of data - Alphanumeric or text data
 Input and output formats - using coding symbols:
• Z - Zero suppress
• 9 - Number
• X - Character
• X(8) - 8 characters
• . , - Comma, decimal point, hyphen
 Valida tion criteria - Ensure that accurate data are captured by the system
 Defau lt value - Include any default value the element may have. The de fault value is
displayed on entry screens
 An ad ditional comment or remark area
Data Stores
 Data stores are created for each different data entity being stored
 When data flow base elements are grouped together to form a structural record, a data
store is created for each unique structural record
 Because a given data flow may only show part of the collective data that a structural
record contains, many different data flow structures may need to be examined to arrive at
a complete data store description
 A data store has:
 The data store ID
 The data store name
 An alias for the table
 A short description of the data store

35
NADAR SARASWATHI COLLEGE OF ENGINEERING AND TECHNOLOGY, THENI.

 The file type

 File format
Eg:

Fig: Sample ata dictionary for employee database

36