Software Engineering

UNIT II
 2
Unit II

Requirements: Importance of Requirement Analysis, User Needs, Software Features

and Software Requirements. Classes of User Requirements : Enduring and Volatile,
Sub phases of Requirement Analysis, Functional and Non-functional requirements,
Barriers to Eliciting User requirements, The software requirements document and
SRS standards, Requirements Engineering, Case Study of SRS for a Real Time
System. Tools for Requirements Gathering: Document Flow Chart, Decision Table,
Decision Tree, Introduction to non-traditional Requirements.

10/4/2021
 3
Importance of Requirement Analysis

The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be
used to develop the requirements of the system.
The following basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good
grasp of the problem:
 What is the problem?
 Why is it important to solve the problem?
 What are the possible solutions to the problem?
 What exactly are the data input to the system and what exactly are the data output by the system?
 What are the likely complexities that might arise while solving the problem?
 If there are external software or hardware with which the developed software has to interface, then what exactly would the
data interchange formats with the external system be?

10/4/2021
 4
User and System Requirements

1. User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must
operate.
2. System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements should define exactly what is
to be implemented. It may be part of the contract between the system buyer and the software
developers.

10/4/2021
5

10/4/2021
 6
Functional and Non-Functional Requirements

 1. Functional requirements These are statements of services the system should provide,
how the system should react to particular inputs, and how the system should behave in
particular situations. In some cases, the functional requirements may also explicitly state
what the system should not do.
 2. Non-functional requirements These are constraints on the services or functions offered
by the system. They include timing constraints, constraints on the development process,
and constraints imposed by standards. Non-functional requirements often apply to the
system as a whole, rather than individual system features or services.

10/4/2021
 7
Functional

 Functional system requirements vary from general requirements covering what the system should do to
very specific requirements reflecting local ways of working or an organization’s existing systems.
 For example, here are examples of functional requirements for the MHC-PMS system, used to maintain
information about patients receiving treatment for mental health problems:
 1. A user shall be able to search the appointments lists for all clinics.
 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend
appointments that day.
 3. Each staff member using the system shall be uniquely identified by his or her eight-digit employee
number.

10/4/2021
 8
Non Functional

• Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services
delivered by the system to its users. They may relate to emergent system properties such as reliability, response time, and store
occupancy.
• Although it is often possible to identify which system components implement specific functional requirements ,it is often more
difficult to relate components to non-functional requirements. The implementation of these requirements may be diffused
throughout the system. There are two reasons for this:
 1. Non-functional requirements may affect the overall architecture of a system rather than the individual components. For
example, to ensure that performance requirements are met, you may have to organize the system to minimize communications
between components.
 2. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements
that define new system services that are required. In addition, it may also generate requirements that restrict existing requirements.
10/4/2021
9

10/4/2021
 10

 1. Product requirements
• These requirements specify or constrain the behavior of the software.
• Examples include performance requirements on how fast the system must execute and how much memory it requires,
reliability requirements that set out the acceptable failure rate, security requirements, and usability requirements.
 2. Organizational requirements
• These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s
organization.
• Examples include operational process requirements that define how the system will be used, development process
requirements that specify the programming language, the development environment or process standards to be used, and
environmental requirements that specify the operating environment of the system.

10/4/2021
 11

 3. External requirements
• This broad heading covers all requirements that are derived from factors external to the
system and its development process.
• These may include regulatory requirements that set out what must be done for the system
to be approved for use by a regulator, such as a central bank; legislative requirements that
must be followed to ensure that the system operates within the law; and ethical
requirements that ensure that the system will be acceptable to its users and the general
public.

10/4/2021
 12

 Requirements evolution during the RE process and after a system has gone into service is inevitable. Developing
software requirements focuses attention on software capabilities, business objectives and other business systems. As the
requirements definition is developed, you normally develop a better understanding of users’ needs. This feeds
information back to the user who may then propose a change to the requirements
 Furthermore, it may take several years to specify and develop a large system. Over that time, the system’s environment
and the business objectives change and the requirements evolve to reflect this.

10/4/2021
 13

 From an evolution perspective, requirements fall into two classes:

 Enduring requirements These are relatively stable requirements that derive from the core activity of the
organization and which relate directly to the domain of the system. For example, in a hospital there will always
be requirements concerned with patients, doctors, nurses, treatments, etc. These requirements may be derived
from domain models that show the entities and relations which characterise an application domain
 Volatile requirements These are requirements that are likely to change during the system development
process or after the system has been become operational. Examples of volatile requirements are requirements
resulting from government health-care policies or healthcare charging mechanisms.

10/4/2021
 14

Harker and others

suggested that volatile
requirements fall into five
classes. Using these as a
base, I have developed
the classification shown
in the following table:

10/4/2021
 15
Why is Getting Good Requirements Hard?

 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 RE process. New stakeholders may emerge and the
business environment change.

10/4/2021
 16
Characteristics of a Good Requirement

 Clear and Unambiguous

 standard structure
 has only one possible interpretation
 Not more than one requirement in one sentence
 Correct
 A requirement contributes to a real need
 Understandable
 A reader can easily understand the meaning of the requirement
 Verifiable
 A requirement can be tested
 Complete
 Consistent
 Traceable

10/4/2021
 17
Characteristics of an SRS

1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
7. Modifiable
8. Traceable

10/4/2021
 18

 An SRS is correct if every requirement included in the SRS represents something required in the final
system.
 An SRS is complete if everything the software is supposed to do and the responses of the software to all
classes of input data are specified in the SRS.
 Correctness and completeness go hand-in-hand; whereas correctness ensures that which is specified is done
correctly, completeness ensures that everything is indeed specified. Correctness is an easier property to
establish than completeness as it basically involves examining each requirement to make sure it represents
the user requirement.

10/4/2021
 19

 Completeness, on the other hand, is the most difficult property to establish; to ensure
completeness, one has to detect the absence of specifications, and absence is much harder to
ascertain than determining that what is present has some property.
 An SRS is unambiguous if and only if every requirement stated has one and only one
interpretation. Requirements are often written in natural language, which are inherently
ambiguous.
 If the requirements are specified in a natural language, the SRS writer has to be especially
careful to ensure that there are no ambiguities.
 One way to avoid ambiguities is to use some formal requirements specification language.

10/4/2021
 20

 The major disadvantage of using formal languages is the large effort required to write an SRS, the high
cost of doing so, and the increased difficulty reading and understanding formally stated requirements
(particularly by the users and clients).
 An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if
there exists some cost-effective process that can check whether the final software meets that requirement.
 This implies that the requirements should have as little subjectivity as possible because subjective
requirements are difficult to verify. Unambiguity is essential for verifiability.

10/4/2021
 21

 As verification of requirements is often done through reviews, it also emphasis that an SRS is understandable, at
least by the developer,the client, and the users.
 Understand ability is clearly extremely important,as one of the goals of the requirements phase is to produce a
document on which the client, the users, and the developers can agree.
 An SRS is consistent if there is no requirement that conflicts with another.
 Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the
same object.
 There may be logical or temporal conflict between requirements that causes inconsistencies.
 This occurs if the SRS contains two or more requirements whose logical or temporal characteristics cannot be
satisfied together by any software system.

10/4/2021
 22

 For example, suppose a requirement states that an event e is to occur before another
event. But then another set of requirements states (directly or indirectly by transitivity)
that event / should occur before event.
 Inconsistencies in an SRS can reflect of some major problems.
 Generally, all the requirements for software are not of equal importance.
 Some are critical, others are important but not critical, and there are some which are
desirable but not very important.

10/4/2021
 23

 Similarly, some requirements are "core" requirements which are not likely to change as time passes, while others are more dependent on
time.
 An SRS is ranked for importance and/or stability if for each requirement the importance and the stability of the requirement are indicated.
Stability of a requirement reflects the chances of it changing in future. It can be reflected in terms of the expected change volumeWriting an
SRS is an iterative process. Even when the requirements of a system are specified, they are later modified as the needs of the client change.
 Hence an SRS should be easy to modify. An SRS is modifiable if its structure and style are such that any necessary change can be made
easily while preserving completeness and consistency.
 Presence of redundancy is a major hindrance to modifiability, as it can easily lead to errors. For example, assume that a requirement is
stated in two places and that the requirement later needs to be changed.

10/4/2021
 24

 If only one occurrence of the requirement is modified, the resulting SRS will be inconsistent.
 An SRS is traceable if the origin of each of its requirements is clear and
 if it facilitates the referencing of each requirement in future development
 Forward traceability means that each requirement should be traceable to some design and code elements.
 Backward traceability requires that it be possible to trace design and code elements to the requirements they
support.
 Traceability aids verification and validation.

10/4/2021
 25

 Of all these characteristics, completeness is perhaps the most important (and hardest to ensure).
 One of the most common problem in requirements specification is when some of the requirements of the
client are not specified.
 This necessitates additions and modifications to the requirements later in the development cycle, which are
often expensive to incorporate.
 Incompleteness is also a major source of disagreement between the client and the supplier.
 The importance of having complete requirements cannot be overemphasized.

10/4/2021
 26
Requirement Process

 The requirement process is the sequence of activities that need to be performed in the
requirements phase and that culminate in producing a high quality document containing
the software requirements specification (SRS)

10/4/2021
 27
Flow of Requirement Process

10/4/2021
 28

 Problem analysis often starts with a high-level "problem statement.“ During analysis the problem domain and the
environment are modeled in an effort to understand the system behavior, constraints on the system, its inputs and outputs,
etc.
 The basic purpose of this activity is to obtain a thorough understanding of what the software needs to provide.
 The understanding obtained by problem analysis forms the basis of requirements specification, in which the focus is on
clearly specifying the requirements in a document.

10/4/2021
 29

 Issues such as representation, specification languages, and tools, are addressed during this
activity. As analysis produces large amounts of information and knowledge with possible
redundancies
 Properly organizing and describing the requirements is an important goal of this activity.
 Requirements validation focuses on ensuring that what has been specified in the SRS are
indeed all the requirements of the software and making sure that the SRS is of good quality.
 The requirements process terminates with the production of the validated SRS.

10/4/2021
 30

 From the specification activity we may go back to the analysis activity. This happens as
frequently some parts of the problem are analyzed and then specified before other parts
are analyzed and specified.
 Furthermore, the process of specification frequently shows shortcomings in the
knowledge of the problem, going for further analysis.
 Once the specification is "complete" it goes through the validation activity.

10/4/2021
 31

 This activity may reveal problems in the specifications itself, which requires going back to the specification
step, or may reveal shortcomings in the understanding of the problem, which requires going back to the
analysis activity.
 During requirements analysis the focus is on understanding the system and its requirements.
 For a complex system-"divide-and-conquer," various structures are used during analysis to represent the
information to help view the system as a series of abstractions. Examples: data flow diagrams and object
diagrams (more about these in the next section).

10/4/2021
 32
General Structure of SRS

1. Introduction 2.4 General Constraints and Abbreviations

3.2.1.1 Functional Requirement 1.1
1.1 Purpose 2.5 Assumptions and Dependencies
3.2.1.n Functional Requirement l.n
1.2 Scope 3. Specific Requirements
3.2.m Mode m
1.3 Definitions, Acronyms, 3.1 External Interface Requirements
3.2.m.l Functional Requirement m.l
1.4 References
3.1.1 User Interfaces
S.2.m.n Functional Requirement m.n
3.1.2 Hardware Interfaces 3.3 Performance Requirements
1.5 Overview
3.1.3 Software Interfaces 3.4 Design Constraints
2. Overall Description
3.1.4 Communication Interfaces 3.5 Attributes
2.1 Product Perspective
3.2. Functional Requirements 3.6 Other Requirements
2.2 Product Functions
3.2.1 Mode 1
2.3 User Characteristics

10/4/2021
 33
Components of SRS

• Functionality
• Performance
• Design constraints imposed on an implementation
• External interfaces

10/4/2021
 34
Functional Requirements

 Functional requirements specify which outputs should be produced from the given inputs. They describe the
relationship between the input and output of the system.
 For each functional requirement, a detailed description of all the data inputs and their source, the units of measure, and
the range of valid inputs must be specified.
 All the operations to be performed on the input data to obtain the output should be specified.
 This includes specifying the validity checks on the input and output data, parameters affected by the operation, and
equations or other logical operations that must be used to transform the inputs into corresponding outputs.
 For example, if there is a formula for computing the output, it should be specified. Care must be taken not to specify
any algorithms that are not part of the system but that may be needed to implement the system.
 These decisions should be left for the designer.

10/4/2021
 35

 An important part of the specification is the system behavior in abnormal situations, like variable input (which
can occur in many ways) or error during computation.
 The functional requirement must clearly state what the system should do if such situations occur.
 Specifically, it should specify the behavior of the system for invalid inputs and invalid outputs.
 Furthermore, behavior for situations where the input is valid but the normal operation cannot be performed
should also be specified.
 An example of this situation is an airline reservation system, where a reservation cannot be made even for valid
passengers if the airplane is fully booked.
 In short, the system behavior for all foreseen inputs and all foreseen system states should be specified.
 These special conditions are often likely to be overlooked, resulting in a system that is not robust.

10/4/2021
 36
Performance Requirements

 This part of an SRS specifies the performance constraints on the software system.
 All the requirements relating to the performance characteristics of the system must be clearly specified.
 There are two types of performance requirements: static and dynamic.
 Static requirements are those that do not impose constraint on the execution characteristics of the system.
 These include requirements like the number of terminals to be supported, the number of simultaneous users to
be supported, and the number of files that the system has to process and their sizes.
 These are also called capacity requirements of the system.

10/4/2021
 37

 Dynamic requirements specify constraints on the execution behavior of the system.

 These typically include response time and throughput constraints on the system.
 Response time is the expected time for the completion of an operation under specified circumstances.
 Throughput is the expected number of operations that can be performed in a unit time.
 For example, the SRS may specify the number of transactions that must be processed per unit time, or what
the response time for a particular command should be.

10/4/2021
 38

 Acceptable ranges of the different performance parameters should be specified, as well as

acceptable performance for both normal and peak workload conditions.
 All of these requirements should be stated in measurable terms.
 Requirements such as "response time should be good" or the system must be able to "process
all the transactions quickly" are not desirable because they are imprecise and not verifiable.
 Instead, statements like "the response time of command x should be less than one second 90%
of the times" or "a transaction should be processed in less than one second 98% of the times"
should be used to declare performance specifications.

10/4/2021
 39

 There may be audit tracing requirements, which require certain kinds of changes, or operations that must be
recorded in an audit file.
 Hardware Limitations: The software may have to operate on some existing or predetermined hardware, thus
imposing restrictions on the design.
 Hardware limitations can include the type of machines to be used, operating system available on the system,
languages supported, and limits on primary and secondary storage

10/4/2021
 40
Design Constraints

 There are a number of factors in the client's environment that may restrict the choices of a
designer.
 Such factors include standards that must be followed, resource limits, operating environment,
reliability and security requirements, and policies that may have an impact on the design of the
system.
 An SRS should identify and specify all such constraints.
 Standards Compliance: This specifies the requirements for the standards the system must
follow.
 The standards may include the report format and accounting procedures.

10/4/2021
 41

 Reliability and Fault Tolerance: Fault tolerance requirements can place a major constraint on how the
system is to be designed. Fault tolerance requirements often make the system more complex and expensive.
 Requirements about system behavior in the face of certain kinds of faults is specified.
 Recovery requirements are often an integral part here, detailing what the system should do if some failure
occurs to ensure certain properties.

10/4/2021
 42

 Security: Security requirements are particularly significant in defense systems and many
database systems. Security requirements place restrictions on the use of certain
commands, control access to data, provide different kinds of access requirements for
different people, require the use of passwords and cryptography techniques, and maintain
a log of activities in the system.
 Given the current security needs even of common systems, they may also require proper
assessment of security threats, proper programming techniques, and use of tools to detect
flaws like buffer overflow.

10/4/2021
 43
External Interface Requirements

 All the interactions of the software with people, hardware, and other software should be clearly specified.
 For the user interface, the characteristics of each user interface of the software product should be specified.
 User interface is becoming increasingly important and must be given proper attention.
 A user manual should be created with all user commands, screen formats, an explanation of how the system
will appear to the user, and feedback and error messages.
 Like other specifications these requirements should be precise and verifiable. So, a statement like "the
system should be user friendly" should be avoided and statements like "commands should be no longer than
six characters" or "command names should reflect the function they perform" used.

10/4/2021
 44

 For hardware interface requirements, the SRS should specify the logical characteristics of each interface
between the software product and the hardware components.
 If the software is to execute on existing hardware or on predetermined hardware, all the characteristics of the
hardware, including memory restrictions, should be specified.
 In addition, the current use and load characteristics of the hardware should be given.
 The interface requirement should specify the interface with other software the system will use or that will
use the system.
 This includes the interface with the operating system and other applications. The message content and
format of each interface should be specified.

10/4/2021
 45
Specification Language

 The language should support the desired qualities of the SRS modifiability,
understandability, unambiguous, and so forth
 As one might expect, many of these characteristics conflict in the selection of a
specification language.
 For example, to avoid ambiguity, it is best to use some formal language.
 But for ease of understanding a natural language might be preferable.

10/4/2021
 46

 If formal languages are to be used, they are often used to specify particular properties or for specific parts of
the system, and these formal specifications are generally contained in the overall SRS, which is in a natural
language.
 In other words, the overall SRS is generally in a natural language, and when feasible and desirable, some
specifications in the SRS may use formal languages.

10/4/2021
 47

 The major advantage of using a natural language is that both client and supplier understand the language.
 However, by the very nature of a natural language, it is imprecise and ambiguous.
 To reduce the drawbacks of natural languages, most often natural language is used in a structured fashion.
 In structured English (for example), requirements are broken into sections and paragraphs.
 Each paragraph is then broken into subparagraphs.
 Many organizations also specify strict uses of some words like "shall," "perhaps," and "should" and try to
restrict the use of common phrases in order to improve the precision and reduce the verbosity and ambiguity

10/4/2021
 48

 To specify formats of inputs or outputs, regular expressions can be very useful.

 Similarly, when discussing systems like communication protocols, finite state automata can be used.
 Decision tables are useful to formally specify the behavior of a system on different combinations of inputs or
settings.
 Similarly, some aspects of the system may be specified or explained using the models that may have been
built during problem analysis.
 Sometimes models may be included as supporting documents that help clarify the requirements and the
motivation better.

10/4/2021
49

10/4/2021
 50
Requirements elicitation and analysis

1. Requirements discovery This is the process of interacting

with stakeholders of the system to discover their requirements.
Domain requirements from stakeholders and documentation are
also discovered during this activity. There are several
complementary techniques that can be used for requirements
discovery.

10/4/2021
 51

2. Requirements classification and organization This activity takes the unstructured collection of requirements,
groups related requirements, and organizes them into coherent clusters. The most common way of grouping
requirements is to use a model of the system architecture to identify sub-systems and to associate requirements
with each sub-system. In practice, requirements engineering and architectural design cannot be completely
separate activities.
3. Requirements prioritization and negotiation Inevitably, when multiple stakeholders are involved,
requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiation. Usually, stakeholders have to meet to resolve differences and agree
on compromise requirements.

10/4/2021
 52

4. Requirements specification The requirements are documented and input into the next
round of the spiral. Formal or informal requirements documents may be produced.

10/4/2021
 53
Understanding requirements from system stakeholders is difficult

Eliciting and understanding requirements from system stakeholders is a difficult process for several
reasons:
1. Stakeholders often don’t know what they want from a computer system except in the most general
terms; they may find it difficult to articulate what they want the system to do; they may make unrealistic
demands because they don’t know what is and isn’t feasible.
2. Stakeholders in a system naturally express requirements in their own terms and with implicit
knowledge of their own work. Requirements engineers, without experience in the customer’s domain,
may not understand these requirements.

10/4/2021
 54

3. Different stakeholders have different requirements and they may express these in different ways.
Requirements engineers have to discover all potential sources of requirements and discover commonalities and
conflict.
4. Political factors may influence the requirements of a system. Managers may demand specific system
requirements because these will allow them to increase their influence in the organization.
5. The economic and business environment in which the analysis takes place is dynamic. It inevitably changes
during the analysis process. The importance of particular requirements may change. New requirements may
emerge from new stakeholders who were not originally consulted.

10/4/2021
 55
Requirements discovery

system stakeholders for the mental healthcare patient information system include:

1. Patients whose information is recorded in the system.

2. Doctors who are responsible for assessing and treating patients.
3. Nurses who coordinate the consultations with doctors and administer some treatments.
4. Medical receptionists who manage patients’ appointments.
5. IT staff who are responsible for installing and maintaining the system.
6. A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
7. Healthcare managers who obtain management information from the system.
8. Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been
properly implemented.

10/4/2021
 56
Interviewing

Types:
1. Closed interviews, where the stakeholder answers a pre-defined set of questions.
2. Open interviews, in which there is no pre-defined agenda. The requirements engineering team
explores a range of issues with system stakeholders and hence develop a better understanding of their
needs.

10/4/2021
 57
Difficult to elicit domain knowledge through
interviews for two reasons

1. All application specialists use terminology and jargon that are specific to a domain. It is impossible for
them to discuss domain requirements without using this terminology. They normally use terminology in
a precise and subtle way that is easy for requirements engineers to misunderstand.
2. Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or
they think it is so fundamental that it isn’t worth mentioning.
For example, for a librarian, it goes without saying that all acquisitions are catalogued before they are
added to the library. However, this may not be obvious to the interviewer, and so it isn’t taken into
account in the requirements

10/4/2021
 58
Effective interviewers have two characteristics

1. They are open-minded, avoid pre-conceived ideas about the requirements, and are willing to listen to stakeholders.
If the stakeholder comes up with surprising requirements, then they are willing to change their mind about the system.
2. They prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by
working together on a prototype system. Saying to people ‘tell me what you want’ is unlikely to result in useful
information. They find it much easier to talk in a defined context rather than in general terms.

10/4/2021
 59
Scenarios

 Scenarios can be particularly useful for adding detail to an outline requirements

description.
1. A description of what the system and users expects when the scenario starts.
2. A description of the normal flow of events in the scenario.
3. A description of what can go wrong and how this is handled.
4. Information about other activities that might be going on at the same time.
5. A description of the system state when the scenario finishes.

10/4/2021
 60
Use cases

 Use cases are a

requirements discovery
technique that were first
introduced in the
 Objectory method (Jacobson
et al., 1993)

10/4/2021
 61
Functional Specification with Use Cases

 Actors
-A person or a system which uses the system being built for achieving some goal.
 Primary actor
-The main actor for whom a use case is initiated and whose goal satisfaction is the main objective of the use
case.
 Scenario
-A set of actions that are performed to achieve a goal under some specified conditions.
 Main success scenario
-Describes the interaction if nothing fails and all steps in the scenario succeed.
 Exceptional scenario
-Describe the system behavior if some of the steps in the main scenario do not complete successfully.

10/4/2021
 62

 key advantage of this approach is that use cases focus on external behavior, thereby cleanly avoiding doing
internal design during requirements, something that is desired but not easy to do with many modeling
approaches.
 Use cases are naturally textual descriptions, and represent the behavioral requirements of the system. This
behavior specification can capture most of the functional requirements of the system. Therefore, use cases do
not form the complete SRS, but can form a part of it.
 The complete SRS, as we have seen, will need to capture other requirements like performance and design
constraints

10/4/2021
 63

• Use Case 1: Put an item up for auction

Primary Actor: Seller
Precondition: Seller has logged in
Main Success Scenario:
1. Seller posts an item (its category, description, picture, etc.) for auction
2. System shows past prices of similar items to seller
3. Seller specifies the starting bid price and a date when auction will close
4. System accepts the item and posts it
Exception Scenarios:
— 2 a) There are no past items of this category
* System tells the seller this situation 10/4/2021
 64

• Use Case 2: Make a bid 4. System accepts the bid; Blocks funds in bidders
Primary Actor: Buyer account
Precondition: The buyer has logged in 5. System updates the bid price of other bidders where
Main Success Scenario: needed, and updates
1. Buyer searches or browses and selects some item the records for the item
2. System shows the rating of the seller, the starting bid, the Exception Scenarios:
current bids, — 3 a) The bid price is lower than the current highest
and the highest bid; asks buyer to make a bid * System informs the bidder and asks to rebid
3. Buyer specifies a bid price, maximum bid price, and an — 4 a) The bidder does not have enough funds in his
increment account
10/4/2021
* System cancels the bid, asks the user to get more funds
 65

• Use Case 3: Complete auction of an item

Primary Actor: Auction System
Precondition: The last date for bidding has been reached
Main Success Scenario:
1. Select highest bidder; send email to selected bidder and seller informing final bid price; send email to other
bidders also,
2. Debit bidder's account and credit seller's
3. Transfer from seller's account. commission amount. to organization's activity.
4. Remove item from the site; update records
Exception Scenarios: None
10/4/2021
 66

 This allows use cases to be hierarchically organized and refinement approach can be used to define a higher
level use case in terms of lower services and then defining the lower services.
 However, these lower-level use cases are proper use cases with a primary actor, main scenario, etc.
 The primary actor will often be the primary actor of the higher level use case.
 For example, the primary actor for the use case "find an item" is the buyer.
 implies that while listing the scenarios, new use cases and new actors might emerge.
 In the requirements document, all the use cases that are mentioned in this one will need to be specified if
they are a part of the system being built.

10/4/2021
 67
Extension

 Use Case 0: Auction an item

 Primary Actor: Auction system
 Scope : Auction conducting organization
 Precondition: None
 Main Success Scenario:
1. Seller performs Put an item for auction
2. Various bidders perform make a bid
3. On final date perform Complete the auction of the item
4. Get feedback from seller; get feedback from buyer; update records

10/4/2021
 68
Developing Use Cases

 Actors and goals. The actor-goal list enumerates the use cases and specifies the actors for each goal. (The name of the use
case is generally the goal.) This table may be extended by giving a brief description of each of the use cases.
 At this level, the use cases specify the scope of the system and give an overall view of what it does.
 Completeness of functionality can be assessed fairly well by reviewing these.
 Main success scenarios. For each of the use cases, the main success scenarios are provided at this level. With the main
scenarios, the system behavior for each use case is specified.
 This description can be reviewed to ensure that interests of all the stakeholders are met and that the use case is delivering the
desired behavior.
 Failure conditions. Once the success scenario is listed, all the possible failure conditions can be identified.
 At this level, for each step in the main success scenario, the different ways in which a step can fail form the failure
conditions

10/4/2021
 69

 Failure handling. This is perhaps the most tricky and difficult part of writing a use case. Often the focus is so
much on the main functionality that people do not pay attention to how failures should be handled.
 Determining what should be the behavior under different failure conditions will often identify new business rules
or new actors.
 For writing use cases, general technical writing rules apply. Use simple grammar, clearly specify who is performing
the step, and keep the overall scenario as simple as possible.
 Also, when writing steps, for simplicity, it is better to combine some steps into one logical step, if it makes sense.
 For example steps "user enters his name," "user enter his SSN," and "user enters his address" can be easily
combined into one step "user enters personal information."

10/4/2021
 70
Ethnography

 Ethnography is an observational
technique that can be used to
understand operational processes and
help derive support requirements for
these processes.
 An analyst immerses himself or
herself in the working environment
where the system will be used

10/4/2021
 71
Ethnography to discover requirements

1. Requirements that are derived from the way in which people actually work, rather than the way in which process
definitions say they ought to work. For example, air traffic controllers may switch off a conflict alert system that detects
aircraft with intersecting flight paths, even though normal control procedures specify that it should be used. They deliberately
put the aircraft on conflicting paths for a short time to help manage the airspace. Their control strategy is designed to ensure
that these aircrafts are moved apart before problems occur and they find that the conflict alert alarm distracts them from their
work.
2. Requirements that are derived from cooperation and awareness of other people’s activities. For example, air traffic
controllers may use an awareness of other controllers’ work to predict the number of aircrafts that will be entering their
control sector. They then modify their control strategies depending on that predicted workload. Therefore, an automated ATC
system should allow controllers in a sector to have some visibility of the work in adjacent sectors.

10/4/2021
 72
Requirements validation

1. Validity checks A user may think that a system is needed to perform certain functions. However, further thought

and analysis may identify additional or different functions that are required. Systems have diverse stakeholders with

different needs and any set of requirements is inevitably a compromise across the stakeholder community.

2. Consistency checks Requirements in the document should not conflict. That is, there should not be contradictory

constraints or different descriptions of the same system function.

3. Completeness checks The requirements document should include requirements that define all functions and the

constraints intended by the system user.

10/4/2021
 73

4. Realism checks Using knowledge of existing technology, the requirements should be checked to ensure that
they can actually be implemented. These checks should also take account of the budget and schedule for the
system development.
5. Verifiability To reduce the potential for dispute between customer and contractor, system requirements should
always be written so that they are verifiable. This means that you should be able to write a set of tests that can
demonstrate that the delivered system meets each specified requirement

10/4/2021
 74

Individual or Conjunction Requirements

1. Requirements reviews The requirements are analyzed systematically by a team of reviewers who check for errors and
inconsistencies.
2. Prototyping In this approach to validation, an executable model of the system in question is demonstrated to end-users and
customers. They can experiment with this model to see if it meets their real needs.
3. Test-case generation Requirements should be testable. 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, this usually means that the
requirements will be difficult to implement and should be reconsidered. Developing tests from the user requirements before
any code is written is an integral part of extreme programming.

10/4/2021
 75
Requirements Management

 The requirements for large software systems are always

changing.
 One reason for this is that these systems are usually
developed to address ‘wicked’ problems—problems that
cannot be completely defined. Because the problem cannot
be fully defined, the software requirements are bound to be
incomplete.
 During the software process, the stakeholders’
understanding of the problem is constantly changing

10/4/2021
 76
Three principal stages to a change management process

1. Problem analysis and change specification The process starts with an identified requirements problem or, sometimes, with a specific change

proposal. During this stage, the problem or the change proposal is analyzed to check that it isvalid. This analysis is fed back to the change requestor

who may respond with a more specific requirements change proposal, or decide to withdraw the request.

2. Change analysis and costing The effect of the proposed change is assessed using traceability information and general knowledge of the system

requirements. The cost of making the change is estimated both in terms of modifications to the requirements document and, if appropriate, to the

system design and implementation. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change.

3. Change implementation The requirements document and, where necessary, the system design and implementation, are modified. You should

organize the requirements document so that you can make changes to it without extensive rewriting or reorganization. As with programs,

changeability in documents is achieved by minimizing external references and making the document sections as modular as possible. Thus, individual

sections can be changed and replaced without affecting other parts of the document.

10/4/2021
 77

 Agile development processes, such as extreme programming, have been designed to cope with requirements
that change during the development process.
 In these processes, when a user proposes a requirements change, this change does not go through a formal
change management process.
 Rather, the user has to prioritize that change and, if it is high priority, decide what system features that were
planned for the next iteration should be dropped.

10/4/2021
 78
Decision tree

 A decision tree gives a graphic view of the processing logic involved in

decision making and the corresponding actions taken. The edges of a
decision tree represent conditions and the leaf nodes represent the actions to
be performed depending on the outcome of testing the condition.
Example: -
 Consider Library Membership Automation Software (LMS) where it should
support the following three options:
􀂃 New member
􀂃 Renewal
􀂃 Cancel membership

10/4/2021
 79

New member option-

 Decision: When the 'new member' option is selected, the software asks details about the member like the member's name, address, phone number etc.
 Action: If proper information is entered then a membership record for the member is created and a bill is printed for the annual membership charge plus the
security deposit payable.
Renewal option-
 Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and his membership number to check whether he is a valid member or not.
 Action: If the membership is valid then membership expiry date is updated and the annual membership bill is printed, otherwise an error message is displayed.

Cancel membership option-

 Decision: If the 'cancel membership' option is selected, then the software asks for member's name and his membership number.
 Action: The membership is cancelled, a cheque for the balance amount due to the member is printed and finally the membership record is deleted from the
database

10/4/2021
 80

 Decision tree representation of the above example -

 The following tree (fig. 3.4) shows the graphical representation of the
above example. After getting information from the user, the system makes
a decision and then performs the corresponding actions.

10/4/2021
81

10/4/2021
 82
Decision table

 A decision table is used to represent the complex processing logic in a tabular or a matrix form.
The upper rows of the table specify the variables or conditions to be evaluated. The lower rows
of the table specify the actions to be taken when the corresponding conditions are satisfied. A
column in a table is called a rule. A rule implies that if a condition is true, then the
corresponding action is to be executed.
Example: -
 Consider the previously discussed LMS example. The following decision table shows how to
represent the LMS problem in a tabular form.
 Here the table is divided into two parts, the upper part shows the conditions and the lower part
shows what actions are taken. Each column of the table is a rule.

10/4/2021
 83

From the table you can easily

understand that, if the valid
selection condition is false then the
action taken for this condition is
'display error message'. Similarly, the
actions taken for other conditions
can be inferred from
the table.

10/4/2021
84

10/4/2021