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

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 Revision Example: Buy Drink Use Case

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 Revision Example: Buy Drink Use Case

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 Revision Example: Buy Drink Use Case

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 Revision Example: Service Machine Use Case

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 Revision Example: Buy Drink Use Case

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 Revision Example: Vending Machine Use Case Diagram

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 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.

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

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

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

Week 4 and 5 Lessons:
Developing Requirement Analysis

 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).

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

Week 4 and 5 Lessons:
Developing Requirement Analysis
 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

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
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.
04/06/2022 Chap-3: Developing Requirement Analysis 13
 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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).
04/06/2022 Chap-3: Developing Requirement Analysis 14
 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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>,

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis

 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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;
04/06/2022 Chap-3: Developing Requirement Analysis 27
 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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,

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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;

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 ISO/IEC/IEEE 29148 Standard for Requirements Analysis.
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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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.
04/06/2022 Chap-3: Developing Requirement Analysis 32
 Week 4 and 5 Lessons:
Developing Requirement Analysis

 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).

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Common Requirements Problems …

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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Common Requirements Problems …

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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Common Requirements Problems …

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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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)”).

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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”).

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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>

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Techniques that should be used to avoid common requirements
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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Techniques that should be used to avoid common requirements
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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Techniques that should be used to avoid common requirements
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”.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 (C)lass (R)esponsability (C)ollaborators cards.
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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 (C)lass (R)esponsability (C)ollaborators cards.
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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 (C)lass (R)esponsability (C)ollaborators cards.

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.”

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 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.

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 CRC Uses

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis

 CRC …

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis

 CRC and Use Cases

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis

 CRC and Use Cases

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
 Example of CRC Card

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis

 Case Study (Requirement)

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis

 ATM candidate Classes

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

Week 4 and 5 Lessons:
Developing Requirement Analysis
o Example of CRC forms

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

Week 4 and 5 Lessons:
Developing Requirement Analysis
o Example of CRC forms …

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

 Week 4 and 5 Lessons:
Developing Requirement Analysis
o Example

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