Developing Requirements Analysis-Exchap3

Software Requirements Engineering (SWEG3104)
Instructor: Behailu Getachew (Asst. Prof.)
Chapter 3- Developing Requirement Analysis
04/06/2022 Chap-3: Developing Requirement Analysis 1

Week 4 and 5 Lessons:
Developing Requirement Analysis
 In summary, the process of requirement elicitation consists of steps

to
 Identify actors
 Identify scenarios
 Identify use cases
 Refine use cases
 Identify relationship between actors and use cases
 Identify initial object analysis
 Identify non-functional requirements

 Revision Example: Buy Drink Use Case



 Revision Example: Service Machine Use Case


 Revision Example: Vending Machine Use Case Diagram

 Home Work: Drink Vending Machine Questions

o URN: User Requirement Notation.
1. Create a URN model for the BuyDrink use case.
 If you decide to group several basic interaction steps
into one URN responsibility, please use the description
field of the responsibility to document which use case
steps it represents.
2. Create a URN model for the ServiceMachine use case.

 Home Work: Use Case Model for Automated Air Traffic Control
System (AATCS).

 Home Work: Consider AATCS use case model to do the following

tasks:
1. Derive the Use Case Descriptions.
2. Suggest and describe at least one main use case
scenarios.
3. Describe the extension (s).

 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
o Requirements Specification:
o Requirements document structure
o Requirements document standard and Guidelines
 (C)lass (R)esponsability (C)ollaborators cards.
o Linking Requirements to UML Analysis Models
o Examples: Case Studies

o Requirement Analysis
o What is it?
o The process by which customer needs are understood and
documented.
o Expresses “what” is to be built and NOT “how” it is to be
built.
o Example 1:
o The system shall allow users to withdraw cash. [What?]
o Example 2:
o A sale item‟s name and other attributes will be stored in a
hash table and updated each time any attribute changes.
[How?]
o How to make a standard requirement analysis?
o Using ISO/IEC/IEEE 29148:2018 standard formulation.
o How to develop the analysis for ensuring such standard?
o Using Requirement Analysis Tool (RAT).
o jUCMNav Tool, ReqIF studio, QUARCC, QuARS, KaOS.
o ISO/IEC/IEEE 29148 Requirement lifecycle: Requirements
engineering follows this document to define the standard
requirement engineering processes for development of software
and hardware products.
o The basic standard for specifying the software requirements is

ISO/IEC/IEEE 29148:2018, which regulates the structure and
required items of the specification.
o The known models, methods and tools analyzed do not enable

to solve the problem of software requirements specification
analysis on its structure correctness (according to
ISO/IEC/IEEE 29148:2018).
o The formalization of the structure of software requirements
specification in the form of set-theoretical models of sections of
the specification has to be defined (according to ISO/IEC/IEEE
29148:2018).
o How to represent the formalized form of software requirements

specification on Its structure correctness (according to
ISO/IEC/IEEE 29148:2018)?
o Given the structure of the specification of the software

requirements in accordance with ISO 29148:2018, let's
represent the specification in the following formalized
form:
SRS=<S_1,...,S_19>,

 ISO/IEC/IEEE 29148 …: SRS=<S_1,...,S_19>,

o where S_1 – section “Purpose” of the software requirements
specification, S_2 – section “Scope”, S_3 – section “Product
perspective”, S_4 – section “Product functions”, S_5 – section “User
characteristics”, S_6 – section “Limitations”, S_7 – section “Assumptions
and dependencies”, S_8 – section “Apportioning of requirements”, S_9 –
section “Specific requirements”, S_10 – section “External interfaces”,
S_11 – section “Functions”, S_12 – section “Usability requirements”,
S_13 – section “Performance requirements”, S_14 – section “Logical
database requirements”, S_15 – section “Design constraints”, S_16 –
section “Standards compliance”, S_17 – section “Software system
attributes”, S_18 – section “Verification”, S_19 – section “Supporting
information” of the software requirements specification.

o SRS=<S_1,...,S_19>,
o SRS is Software Requirement Specification.
o S_1 = {ps},
o ps – purpose of software;
o S_2 = {isp, spd, spb, spo, spg, cssh},

o isp – the software product's identifying,
o spd– what software product will provide,
o spb – benefit of the software product,
o spo – objectives of the software product,
o spg – goals of the software product,
o cssh – consistency with the same statements in high-level
specifications;

o SRS=<S_1,...,S_19>,
o S_3 = {srrp, sosi, soui, sohi, soswi, soci, som, soo, sosar},
o srrp – software system's relationship to other related
products,
o sosi – software operation within the system interfaces,
o soui – software operation within the user interfaces,
o sohi – software operation within the hardware interfaces,
o soswi – software operation within the software interfaces,
o soci – software operation within the communications
interfaces,
o som – software operation within the memory,
o soo – software operation within the operations,
o sosar – software operation within the site adaption
requirements

o SRS=<S_1,...,S_19>,
o S_4 = {mf},
o mf– major future functions of the software.
o S_5 = {gcigu, gciu},

o gcigu – general characteristics of the software product's
groups of users,
o gciu – general characteristics which influence usability;

o SRS=<S_1,...,S_19>,
o S_6 = {rp, hwl, ioa, plo, af, cf, holr, shp, quar, ca, ssc, pmc},
o rp – regulatory policies,
o hwl –limitations of hardware,
o ioa – interfaces to other applications,
o plo – parallel operation,
o af – audit functions,
o cf – control functions,
o holr – requirements of higher-order language,
o shp – protocols of signal handshake,
o quar – quality requirements,
o ca – criticality of the application,
o ssc – considerations of safety and security,
o pmc – physical/mental considerations

o SRS=<S_1,...,S_19>,
o S_7 = {far},
o far – factors which influence the requirements;
o S_8 = {asrse, crtf, crte, rduf},

o asrse – distribution the requirements to elements of
software,
o crtf – cross-reference table by function,
o crte – cross-reference table by element,
o rduf – requirements that can be transferred in software's
future versions;

o SRS=<S_1,...,S_19>,
o S_9 = {rlds, iss, oss, fss},
o rlds – requirements to a detail sufficient level,
o iss – inputs into the software system,
o oss – outputs from the software system,
o fss – functions of the software system in response to the
input or in support of the output;

o SRS=<S_1,...,S_19>,
o S_10 = {ni, dp, sido, vrat, um, tg, roio, sfo, wfo, df, cmf, emsg},
o ni – item's name,
o dp – purpose's description,
o sido – input's source or output's destination,
o vrat – valid range, accuracy, and/or tolerance,
o um – measuring units,
o tg – timing,
o roio – relationships to other inputs/outputs,
o sfo – formats/organization of screen,
o Wfo – formats/organization of window,
o df – formats of data,
o cmf – formats of command,
o emsg – end messages;

o SRS=<S_1,...,S_19>,
o S_11 = {faapi, fapgo, vci, eso, ras, ep, rsoi},
o faapi – basic actions that must take place in the software
when receiving and processing inputs,
o fapgo – basic actions that must occur in the software when
processing and generating outputs,
o vci – checks of validity on the inputs,
o eso –exact sequence of operations,
o ras – responses to abnormal situations,
o ep – parameters„ effect,
o rsoi – relationship of inputs and outputs;

o SRS=<S_1,...,S_19>,
o S_12 = {ubr, mec, mefc, msc},
o ubr – usability requirements,
o mec – measurable criteria of effectiveness in specific use
contexts,
o mefc– measurable criteria of efficiency in specific use
contexts,
o msc– measurable criteria of satisfaction in specific use
contexts;

o SRS=<S_1,...,S_19>,
o S_13 = {snr, dnr, nts, nssu, athi, nota, not, adnw, adpw, prq},
o snr – static numerical requirements,
o dnr – dynamic numerical requirements,
o nts – number of supported terminals,
o nssu – number of supported simultaneous users,
o athi – amount and type of handled information,
o nota – numbers of transactions,
o not – number of tasks,
o adnw – amount of the processed data within certain time
periods for normal workload conditions,
o adpw – amount of the processed data within certain time
periods for peak workload conditions,
o prq – requirements of performance

o SRS=<S_1,...,S_19>,
o S_14 = {tiuvf, fqu, asc, der, ics, drr},
o tiuvf – types of used information,
o fqu – frequency of use,
o asc – accessing the capabilities,
o der – entities of data and their relationships,
o ics – constraints of integrity,
o drr – requirements of data retention;
o S_15 = {ces, crr, cpl},

o ces – the software system design's constraints which are
imposed by external standards,
o crr – the software system design's constraints which are
imposed by regulatory requirements,
o cpl – the software system design's constraints which are
imposed by project limitations;
o SRS=<S_1,...,S_19>,
o S_16 = {rf, dn, ap, at},
o rf – report format,
o dn –data naming,
o ap – accounting procedures,
o at – audit tracing

o SRS=<S_1,...,S_19>,
o S_17 = {rb, avb, scr, cct, slhd, fdm, csa, dicv, dp, mb, pb,
pehdc, pchd, uppl, upcls, upos},
o rb – reliability,
o avb –availability,
o scr – security,
o cct – certain techniques of cryptographic,
o slhd – data sets of specific log or history,
o fdm – certain functions to different modules,
o csa – communications between some areas of the software
product,
o dicv – integrity of data for critical variables,
o dp – privacy of data,
o mb – maintainability,

o SRS=<S_1,...,S_19>,
o S_17 = {rb, avb, scr, cct, slhd, fdm, csa, dicv, dp, mb, pb,
pehdc, pchd, uppl, upcls, upos},
o pb – portability,
o pehdc – the percentage of elements with host-dependent
code,
o pchd – the percentage of host dependent code,
o uppl – portable language use,
o upcls – particular compiler or language subset use,
o upos – operating system use;

o SRS=<S_1,...,S_19>,
o S_18 = {va, mqs},
o va – approaches for verification,
o mqs – methods for qualifying the software;
o S_19 = {siof, dcas, rus, sbi, dpss, spi},

o siof – sample input/output formats,
o dcas – cost analysis studies' descriptions,
o rus – user surveys' results,
o sbi – supporting or background information that can help
the readers of the SRS,
o dpss – description of the problems which will be solved by
the software,
o spi – special packaging instructions for the code and the
media for security, export, initial loading.

 How to discover whether an ideal and a real ontology analysis that
supports the correct requirement specification or not?
o The equations S_1 - S_19 represent all the necessary items of

the software requirements specification in terms of
ISO/IEC/IEEE 29148:2018, structured by the sections of the
specification.
o For the structure of the specification of requirements to be

recognized as correct, it is necessary that the specification
contains all the listed items.
o For ensuring all items availability, it is proposed to develop an

ideal ontology based on the equations S_1 - S_19 as well as to
develop a real ontology based on each analyzed specification.
o A comparison of the two ontologies (ideal and real) should

result in the correct requirement items of specification being set.
 How to discover whether an ideal and a real ontology analysis that

supports the correct requirement specification or not …?
o Case 1: If either of the availability of items are missed, then

the structure of specification is incorrect and re-work of the
specification is proposed.
o Case 2: If there are no such missing items, then the structure

of specification is correct and further work is proposed.
o The use of ontologies in this approach to the analysis of software

requirements specification on its structure correctness provides
the automation of analysis (according to ISO/IEC/IEEE
29148:2018).

 Real vs Ideal Ontology Comparison Diagram:
 This diagram below depicts to provide the realization
of the ideal and the real ontology analysis in the
practical world, and support the flow of the correct
software requirement specification.

 Requirements Specification Document (RSD)
o This document describes each of the essential requirements
(functions, performance, design constraints, and quality
attributes) of the system / software and its external interfaces.
o Defines the scope and boundaries of the system / software.
o Elaborated from elicitation notes.
o Reading Assignment:
o IEEE 830 and IEEE 29148 Standards and Guidelines for
formation of RSD.
o Use these two IEEE standards for document structure and

requirement specification guidelines.

 Common Requirements Problems
o Requirements that are easy to misunderstand.

o Often, this problem is caused by the use of ambiguous
terms, terminological inconsistencies or the use of non-
standard syntaxes for documenting requirements.
• Use of ambiguous terms. Consider the requirement “The

Payroll Database shall respond to all queries quickly”. It is
unclear what “quickly” means in this context (1 ms, 1
sec, 10 sec, etc.) and this may lead to a mismatch
between the expectations of the stakeholder and the
interpretation of the developer, ultimately leading to
rework and/or customer dissatisfaction.

 Common Requirements Problems …
o Often, this problem …

• Terminological inconsistency. Consider the following
requirements: 1) “The Order Entry System shall allow users
to view all orders placed in a day” and 2) “The Order
Processing System shall generate daily reports”. In this case,
the requirements analyst uses two different terms to refer
to the same system, leading to confusion.

o Often, this problem …

• Use of non-standard syntaxes such as missing agent.
Consider the requirement “Shall have the ability to generate
profit reports”. It is unclear which agent (e.g., which system
or sub-system) shall have the ability to generate the profit
reports. In this case, the designers/developers may try to
guess which system should have that functionality,
potentially leading to rework at a later phase.

o Requirements that are inconsistent.

o This problem is caused by requirements either conflicting
with each other or with some policy or business rule.
o Example: Consider the following two requirements: “The

Payroll database shall authenticate all requests using
LDAP” and “The payroll database must respond to all
requests within 1 millisecond”. In this case, it may not
be feasible to satisfy this requirement if the LDAP server
takes more than 1 millisecond to process each request.
If such a defect is not detected early on, then it is
possible that the infeasibility is only realized when the
LDAP server and the Payroll database have been
designed and implemented, leading to large costs in
rework.

o Requirements that are incomplete.

o This problem is caused by missing some requirements of a
certain type.
o Example: It is often the case that performance
requirements for a system are omitted either due to the
lack of knowledge among the stakeholders or because
the requirements analysts fail to elicit them. This
leaves the technical designers and developers to make
design choices about the software system, which may
or may not meet the stakeholder’s approval.

 Some practices to avoid common requirements problems …
o Use the best practices for writing requirements.

o Write complete sentences that have proper spelling and
grammar.
o Use active voice (For e.g., “ The System shall send an e-mail”
instead of “E-mail will be sent”) .
o Use terms consistently and as defined in the glossary.
o Do not use different phrases to refer to the same thing. (For
e.g., Do not use Order Processing System and Order Entry
System to refer to the same system).
o Write sentences in a consistent fashion starting with the
agent/actor, followed by an action verb, followed by an
observable result. (For e.g., “The System (agent) shall
generate (action verb) a report (result)”).

 Some practices to avoid common requirements problems …
o Use the best practices for writing requirements ….
o Clearly specify the trigger condition that causes the system
to perform a certain behavior. (For e.g., “If the user enters the
wrong password, the system shall generate an error
message”).

 Techniques that should be used to avoid common requirements
problems
o Example: Syntactic and phrasal analysis: using

Requirements Analysis Tool (RAT).
o RAT supports a set of controlled syntaxes for writing
requirements. This set includes ..
o Standard Requirements Syntax. This is the most
commonly used syntax for writing requirements and is
of the form:
o StandardRequirement: <agent> <modal word>

<action> <rest>

problems …
o Standard Requirements Syntax …
o Where, <agent>, <action>, <modal word> are phrases in
their respective glossaries and <rest> is the remainder of
the sentence and can consist of agents, actions or any other
words and is defined as:
o <rest>: [<anyword> | <agent> | <action>]*
o Example of standard requirement: “The system shall

generate profit reports.” Here “System” is the agent, “shall”
is the modal word and “generate” is the action and “profit
reports” is the rest of the requirement.

problems …
o Conditional Requirements Syntax.
o There are a number of conditional requirements
supported by RAT.
o For brevity, the most common condition syntax is:
o <“if”> <condition> <“then”> <StandardRequirement>
o Consider the following requirement: “If the user enters

the wrong password, then the system shall send an error
message to the user.” In the case, “user enters the wrong
password” is the condition. The part after “then” is treated
like a standard requirement.

problems …
o Business Rules Syntax. RAT treats all requirements that start

with “all”, “only” and “exactly” as business rules.
o An example is: “Only the members of payroll department
will be able to access the payroll database”.

o Helps to link Requirements to UML Analysis Models.
o A CRC is a brainstorming technique for designing interactions in
use cases by assigning responsibilities and collaborations for
classes.
o A CRC card is a card layout for a single class and identifies the
class and its attributes, its responsibilities, i.e., functions, and
its collaborations, i.e. the methods in its API.

o Helps to link Requirements to UML Analysis Models.
o CRC is a portable and an anthropomorphic.
o What Is Anthropomorphism? Anthropomorphism is a literary

device that assigns human characteristics to nonhuman entities
like animals or inanimate objects.
o Anthropomorphic means treating animals and objects as if they

are human in appearance.

o Example: How to Write Anthropomorphism?
o On Sep 21, 2021, written by the MasterClass staff,

“Some of the most compelling stories we tell as human beings are
not about humans at all. For most of human history, people have
told stories in which animals or inanimate objects act in human-like
ways. The term for this is anthropomorphism. As a writer or
storyteller, understanding and using anthropomorphism in your
work can open up a whole new world of fantastical characters and
settings for you to explore.”

 What is CRC Card ?
o Class
o An object-oriented class name.
o Include information about super- and sub-classes.
o Responsibility
o What information this class stores?
o What this class does?
o The behavior for which an object is accountable.
o Collaboration
o Relationship to other classes.
o Which other classes this class uses.
 CRC Model?
o A CRC Model is a collection of CRC cards.

 CRC Uses

 CRC …

 CRC and Use Cases

 CRC and Use Cases

 Example of CRC Card

 Case Study (Requirement)

 ATM candidate Classes

o Example of CRC forms

o Example of CRC forms …

o Example

Developing Requirements Analysis-Exchap3

Uploaded by

Copyright:

Available Formats

Developing Requirements Analysis-Exchap3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Developing Requirements Analysis-Exchap3

Uploaded by

Copyright:

Available Formats

Software Requirements Engineering (SWEG3104)

Instructor: Behailu Getachew (Asst. Prof.)

Chapter 3- Developing Requirement Analysis

04/06/2022 Chap-3: Developing Requirement Analysis 1

 In summary, the process of requirement elicitation consists of steps

04/06/2022 Chap-3: Developing Requirement Analysis 2

 Revision Example: Buy Drink Use Case

04/06/2022 Chap-3: Developing Requirement Analysis 3

 Revision Example: Buy Drink Use Case

04/06/2022 Chap-3: Developing Requirement Analysis 4

 Revision Example: Buy Drink Use Case

04/06/2022 Chap-3: Developing Requirement Analysis 5

 Revision Example: Service Machine Use Case

04/06/2022 Chap-3: Developing Requirement Analysis 6

 Revision Example: Buy Drink Use Case

04/06/2022 Chap-3: Developing Requirement Analysis 7

 Revision Example: Vending Machine Use Case Diagram

04/06/2022 Chap-3: Developing Requirement Analysis 8

 Home Work: Drink Vending Machine Questions

04/06/2022 Chap-3: Developing Requirement Analysis 9

04/06/2022 Chap-3: Developing Requirement Analysis 10

 Home Work: Consider AATCS use case model to do the following

04/06/2022 Chap-3: Developing Requirement Analysis 11

04/06/2022 Chap-3: Developing Requirement Analysis 12

o The basic standard for specifying the software requirements is

o The known models, methods and tools analyzed do not enable

o How to represent the formalized form of software requirements

o Given the structure of the specification of the software

04/06/2022 Chap-3: Developing Requirement Analysis 15

 ISO/IEC/IEEE 29148 …: SRS=<S_1,...,S_19>,

04/06/2022 Chap-3: Developing Requirement Analysis 16

o S_2 = {isp, spd, spb, spo, spg, cssh},

04/06/2022 Chap-3: Developing Requirement Analysis 17

04/06/2022 Chap-3: Developing Requirement Analysis 18

o S_5 = {gcigu, gciu},

04/06/2022 Chap-3: Developing Requirement Analysis 19

04/06/2022 Chap-3: Developing Requirement Analysis 20

o S_8 = {asrse, crtf, crte, rduf},

04/06/2022 Chap-3: Developing Requirement Analysis 21

04/06/2022 Chap-3: Developing Requirement Analysis 22

04/06/2022 Chap-3: Developing Requirement Analysis 23

04/06/2022 Chap-3: Developing Requirement Analysis 24

04/06/2022 Chap-3: Developing Requirement Analysis 25

04/06/2022 Chap-3: Developing Requirement Analysis 26

o S_15 = {ces, crr, cpl},

04/06/2022 Chap-3: Developing Requirement Analysis 28

04/06/2022 Chap-3: Developing Requirement Analysis 29

04/06/2022 Chap-3: Developing Requirement Analysis 30

o S_19 = {siof, dcas, rus, sbi, dpss, spi},

04/06/2022 Chap-3: Developing Requirement Analysis 31

o The equations S_1 - S_19 represent all the necessary items of

o For the structure of the specification of requirements to be

o For ensuring all items availability, it is proposed to develop an

o A comparison of the two ontologies (ideal and real) should

 How to discover whether an ideal and a real ontology analysis that

o Case 1: If either of the availability of items are missed, then

o Case 2: If there are no such missing items, then the structure

o The use of ontologies in this approach to the analysis of software