ChapterFour

Putting together requirements gathering

team

1
 Chapter
Outline
 Fundamental requirements gathering techniques

 Essential Use Case Modeling

 Essential User Interface Prototyping

 Domain modeling with class responsibility collaborator (CRC)

cards

 Developing a supplementary Specification

 Identifying Change Cases

2 2
 Fundamental requirements gathering
techniques
 Individually interview people informed about the operation and issues of the
current
system and future systems needs.
 Interview groups of people with diverse needs to fid interactions and contrasts
among system requirements
 Observe workers at selected times to see how data are handled and what
information
people need to do their jobs.
 Study business documents/document analysis to discover reported issues, policies,
rules, and directions as well as concrete examples of the use of data and information
in the org.
 What can the analysis of documents tell you about the requirements for a7 new
 Cntd…
 In documents you can find information about the following:
 Problems with existing systems (e.g., missing information or redundant steps
 Opportunities to meet new needs if only certain information or information
processing were available (e.g., analysis of sales based on customer type)
 Organizational direction that can influence information system requirements (e.g.,
trying
to link customers and suppliers more closely to the organization)
 Titles and names of key individuals who have an interest in relevant existing systems
(e.g., the name of a sales manager who led a study of the buying behavior of key
customers)
 Values of the organization or individuals who can help determine priorities for
different capabilities desired by different users (e.g., maintaining market share even
if it means lower short-term profits
7
 An Overview of Requirements
Elicitation
 Requirements elicitation focuses on describing the purpose of the system.
 The client, the developers, and the users identify a problem area and define a
system
that addresses the problem.
 Such a definition is called a requirements specification and serves as a
contract
between the client and the developers.
 The requirements specification is structured and formalized during analysis to
produce an analysis model.
 Both requirements specification and analysis model represent the same information.
 They differ only in the language and notation they use;
 the requirements specification is written in natural language,
7
 Cntd
…
 The requirements specification supports the communication with the client and users.
 The analysis model supports the communication among developers.
 Both models represent the same aspects of the system, requirements elicitation and
analysis occur concurrently and iteratively.
 Requirements elicitation and analysis focus only on the user’s view of the system.
 For example, the system functionality, the interaction between the user and the
system, the errors that the system can detect and handle, and the environmental
conditions in which the system functions are part of the requirements.
 The system structure, the implementation technology selected to build the system, the
system design, the development methodology, and other aspects not directly visible
to user are not part of the
the
requirements. 7
 Cntd
…
Requirements elicitation includes the following activities:
 Identifying actors. During this activity, developers identify the different types of
users
the future system will support.
 Identifying scenarios. During this activity, developers observe users and develop a set
of
detailed scenarios for typical functionality provided by the future system. Scenarios
are
concrete examples of the future system in use. Developers use these
scenarios to communicate with the user and deepen their understanding of the
application domain.
 Identifying use cases. Once developers and users agree on a set of scenarios,
 When describing use cases, developers determine the scope of the
developers derive from the scenarios a set of use cases that completely represent the
7
system.
 Cntd
 Refining use cases. … developers ensure that the requirements
During this activity,
specification is complete by detailing each use case and describing the behavior of the
system in the presence of errors and exceptional conditions.
 Identifying relationships among use cases. During this activity, developers identify
dependencies among use cases. They also combine the use case model by factoring
out
common functionality.
 This ensures that the requirements specification is consistent.
 Identifying nonfunctional requirements. During this activity, developers, users, and
clients agree on aspects that are visible to the user, but not directly related to
functionality.
 These include constraints on the performance of the system, its documentation,
7
the
 Cntd
 During requirements elicitation, …
developers access many different sources of
information, including client-supplied documents about the application domain,
manuals and technical documentation of legacy systems that the future system will
replace, and most important, the users and clients themselves.
 Developers interact the most with users and clients during requirements elicitation.
 We focus on two methods for eliciting information, making with users
and
decisions clients, and managing dependencies among requirements and other
 Joint Application Design (JAD) focuses on building consensus among developers, users,
artifacts:
and
clients by jointly developing the requirements specification.
 Traceability focuses on recording, structuring, linking, grouping, and
maintaining dependencies among requirements and between requirements and other
7
 Cntd
…

National ID system for citizen Use case

diagram 7
 Cntd
…

use case table for

login 7
 Requirements Elicitation Concepts
 In this section, we describe the main requirements elicitation concepts used.

 In particular, we describe

 Functional Requirements

Nonfunctional Requirements

Functional Requirements
 Functional requirements describe the interactions between the and
its
system environment independent of its implementation.
 The environment includes the user and any other external system with which
the system interacts.

7
 Cntd…
Nonfunctional Requirements describe aspects of the system that are not directly related
to
the functional behavior of the system.
 It include a broad variety of requirements that apply to many different aspects
of the system, from usability to performance.
 The following are categories of nonfunctional requirements:
 Usability is the ease with which a user can learn to operate, prepare inputs for,
and interpret outputs of a system or component.
 Usability requirements include, for example, conventions adopted by the user
interface,
the scope of online help, and the level of user documentation.
 Often, clients address usability issues by requiring the developer to follow user
7
interface
 Cntd
 …
Reliability is the ability of a system or component to perform its required
functions
under stated conditions for a specified period of time. Reliability requirements
include,
 for example, an acceptable mean time to failure and the ability to detect specified faults
or to withstand specified security attacks.
 Dependability includes reliability, robustness (the degree to which a system or
component can function correctly in the presence of invalid inputs or stressful
environment conditions), and safety (a measure of the absence of catastrophic
consequences to the environment).
 Performance requirements are concerned with quantifiable attributes of the system,
work the system can accomplish within a specified amount of 7
such as response time (how quickly the system reacts to a user input), throughput
time),
 Cntd
…
 Availability (the degree to which a system or component is operational and
accessible

when required for use), and accuracy.

 Supportability requirements are concerned with the ease of changes to the system after

deployment, including for example, adaptability (the ability to change the system to

deal with additional application domain concepts), maintainability (the ability to

change the system to deal with new technology or to fix defects), and

internationalization (the ability to change the system to deal with additional

international conventions, such as languages, units, and number formats). 7

 User Interface
Prototyping
 User interface (UI) prototyping is an iterative analysis technique in which users
are
actively involved in the mocking -up of the UI for a system.
 UI prototypes have several purposes: As an analysis artifact that enables you
to explore the problem space with your stakeholders
 Domain modeling with class responsibility collaborator (CRC)
cards
 Domain Modeling is a way to describe and model real world entities and
the
relationships between them, which collectively describe the problem domain space.
 Derived from an understanding of system-level requirements, identifying domain
entities and their relationships provides an effective basis for understanding and helps
practitioners design systems for maintainability, testability, and incremental
development. Because there is often a gap between understanding the problem domain
and the interpretation of requirements.
 Class-responsibility-collaborator cards (CRC cards) are not a part of the UML
specification, but they are a useful tool for organizing classes during analysis and
design.
 A CRC card is a physical card representing a single 7
class.
 Cntd
…
 Each card lists the class's name, attributes and methods (its responsibilities), and
class
associations (collaborations).
 The collection of these CRC cards is the CRC model.

 Using CRC cards is a straightforward addition to object-oriented analysis and

design:
 Identify the classes.
 List responsibilities.
 List collaborators.
 CRC cards can be used during analysis and design while classes are being discovered
in order to keep track of them.
7
 Cntd
…
 A ``collaborator'' for a class (``class A'') is another class (``class B'') that receives a
message from class A, sent because the class A needs one of the class B's services to be
performed, in order for one of class A's responsibilities to be fulfilled. you should list
class B as a collaborator of class A, by listing class B in the ``collaborator'' column on
class A's index card, to the right of the listing for the responsibility that required the
message to be sent.

7
 Developing a supplementary
Specification
 The Supplementary Specification provides an overview of the entire document.

 It includes the purpose, scope, definitions, acronyms, abbreviations, references,

and
overview of this Supplementary Specification.
 It also captures the system requirements that are not readily captured in the use cases
of
the use-case model. Such requirements include:
 Legal and regulatory requirements, including application standards.

 Quality attributes of the system to be built, including usability,

reliability, performance, and supportability requirements.
 Other requirements such as operating systems and
7
environments, compatibility requirements, and design
 Cntd…
Purpose
 The purpose of the Supplementary Specification is to capture the system
requirements
that are not readily captured in the use cases of the use-case model.
 It includes requirements such as legal and regulatory requirements, application
standards, quality attributes of the system to be built (usability, reliability,
performance, and supportability requirements) and other requirements such as operating
systems and environment, compatibility requirements and design constraint.

7
 Identifying Change Cases
 Change cases are used to describe new potential requirements for a system
or
modifications to existing requirements.
 Change cases are modeled in a simple manner.

 You describe the potential change to your existing requirements, indicate the
likeliness
of that change occurring, and indicate the potential impact of that change.
 Figure 1 presents two change cases, one potential change that is motivated by technical
innovation-in this case the use of the Internet-and a second by a change in your
business environment. Notice how both change cases are short and to the point, making
them easy-to-understand.
7
 The name of a change case should describe the potential change itself.
 Cntd…

figure: change
7
case
 Cntd…
 Change cases can be identified throughout the course of your overall development
effort.
 Change cases are often the result of brainstormingwith your stakeholders.
Good
questions to consider include:
 How can the business change?
 What is the long-term vision for our organization?
 What technology can change?
 What legislation can change?
 What is your competition doing?
 What systems will we need to interact with?
7
 Ensuring Your Requirements Are
correct: Requirement validation
Techniques

1
 Chapter
Outline
 Testing Early and Often

 Use Case Scenario Testing

2 2
 Requirements Validation
 Validation denotes checking whether inputs, performed activities, and created outputs
(requirements artifacts) of the requirements engineering core activities fulfill defined
quality criteria.
 Validation is performed by involving relevant stakeholders, other requirement
sources
(standards, laws, etc.) as well as external reviewers, if necessary.
Quality Criteria
 Completeness: The requirement must contain all relevant information (template).
 Consistency: The requirements must be compatible with each other.
 Adequacy: The requirements must address the actual needs of the system.
 Unambiguity: Every requirement must be described in a way that precludes
different interpretations. . 3
 Comprehensibility: The requirements must be understandable by the stakeholders
 Cntd
…
 Importance: Each requirement must indicate how essential it is for the success of the project.

 Measurability: - The requirement must be formulated at a level of precision that

enables
to evaluate its satisfaction.
 Necessity: The requirements must all contribute to the satisfaction of the project
goals.
 Viability: All requirements can be implemented with the available technology, human
resources and budget.
 Traceability: The context in which a requirement was created should be easy to
retrieve.
 In System development “the earlier the error is discovered the cheaper it is
correct” 4
 Principles of
Validation
The 6 Principles of Validation
1.Involving the Right Stakeholders: Ensure that relevant company-internal as well as relevant
external stakeholders participate in validation. Pay attention to the reviewers’ independence
and appoint external, independent stakeholders, if necessary.
2. Defect Detection vs. Defect Correction: Separate defect detection from the correction of
the
detected defects.
3.Leveraging Multiple Independent Views: Whenever possible, try to obtain independent
views that can b e integrated during requirements validation in order to detect defects more
reliably.
4.Use of Appropriate Documentation Formats: Consider changing the documentation format
of the requirements into a format that matches the validation goal and the preference s of
stakeholders who actually perform the 5
 Cntd
5.Creation of Development Artifacts
…
during Validation: If your validation approach
generates results, try to support defect detection by creating development artifacts such as
architectural artifacts, test artifacts, user manuals, or goals and scenarios during
validation.

6. Repeated Validation: Establish guidelines that clearly determine when or under

what
conditions an already released requirements artifact has to b e validated again

3
0
 Validation
 Validation Techniques
Techniques
 Inspections
 Desk-Checks
 Walkthroughs
 Prototypes

 Inspection: an organized examination process of the

requirements

7
 Cntd
 Desk-Checks …
 The author of a requirement artifact distributes the artifact to
a set of
stakeholders.
 The stakeholders check the artifact individually.

 The stakeholders report the identified defects to the author.

 The collected issues are discussed in a group session (optional)

7
 Cntd
 Walkthrough …
 A walkthrough does not have formally defined procedure and does not
require a
differentiated role assignment.
 Checking early whether an idea is feasible or not.

 Obtaining the opinion and suggestions of other people.

 Checking the approval of others and reaching agreement.

33
 Prototype
 A prototype allows the s
stakeholders to try out the requirements for the system
and
experience
 them thereby.

 Develop the prototype (tool support).

 Training of the stakeholders.

 Observation of prototype usage.

 Collect issues

34
 What is Early Testing: Test Early, Test Often BUT
How?
What is E arly Testing?
 Software testing should start early in the Software Development Life Cycle.

 This helps to capture and eliminate defects in the early stages of SDLC i.e
requirement gathering and design phases.
 An early start to testing helps to reduce the number of defects and ultimately the
rework cost in the end.
 The various aspects of Early Testing which would help the Managers and Leads
while developing or devising the Testing Strategy document in SDLC.
 Adoption of Early Test will immensely result in the successful delivery of a Quality
Product.
35
Principles of
Testing

36
 Cntd…
 For a given Software or System or Product release in SDLC, there are various
well-
defined methodologies or strategies for most of the following Principles of Testing.
 So, the following questions should answer?

 What is Testing?

 Why Testing?

 What to Test?

 How to Test?

 For easy understanding of the audience, we have included all the ‘grey area’
under one umbrella called E arly
questions
13
 Cntd… .
Why Testing Early in SDLC?
Some events and activities which are a part of testing.
 The Program Management Team assigns a Program Manager (PM) to a given Software
Release or a Project.
 The PM in collaboration with all the stakeholders including Marketing,
Development,
QA (Quality Assurance )and Support teams comes up with a Release
Schedule Software Release Testing Schedule
 Most of the organizations still follow the traditional Time Based Release (TBR) models
where the Software or Product releases are planned for quarterly or half-yearly or
yearly delivery.
 Predominantly, the Waterfall model is used for executing such Software releases.38
Cntd…

Impact of Critical or High Severity 39

Defects
Cntd…

Figure testing effect 40

: profile
 Cntd…
 Mainly, during the course of Testing, it is expected that

 Critical or high severity defects be identified and logged by Testers.

 Developers will need to fix those defects.

 Subsequently, testers will need to verify the fixes.

 Secondly, it is widely acknowledged by many Product and Software Engineering

organizations that fixing and verifying high severity or critical bugs at a very large
number is
 Time-consuming
 Resource hogging (human + machine)
 Prone to collateral(security), fixing critical bugs mostly touch a large part of
the
code including the intersection 17
 Cntd…
 Lastly, if a large number of critical bugs are found during the end of a given release
 Then, one or more of the following negative developments take place.
 High probability of Testing cycle being extended.
 High probability of release deadline being missed.
 A particular feature having a large number of defects, pulled out from that
particular release.
 Customer commitments are being missed.
 How about the other Defects? There are medium and low-priority defects that will
be
identified and logged by the Testers.
 It is a well-known fact that no amount of Testing can extract every defect that a
Software Product or System has.
 Meaning, practically, neither there is an end to testing nor the product is defect-free.
 Cntd…
 However, from the ‘Serviceability’ point of view in a Competitive and Time To
Market

(TTM) model, there is a need to break the typical mindset to unearth maximum

defects early in a Release cycle, especially identification of critical and high severity

defects.

 Any or all of the above will have a negative impact on the Organization’s business.

 In this context, adopting ‘Early Testing’ as a separate Test activity will be beneficial

for the overall management of SDLC for a given Project or Release.

The Scope of Early Testing Effort: Testing Early as a new activity to be tracked exclusively
effort as explained 19
 Cntd…
Assumption:
 The entire Project or Software Release schedule is approved and made available to all
the
stakeholders.
 Overall Test Strategy document is developed, reviewed, and approved by all
the
stakeholders.
 High, Medium, Low priority features to be tested are well documented.
 Test Plans and Test cases for all the Features are developed, reviewed, and approved by
all the stakeholders.
 All Test Plans and Test Cases are uploaded to a central repository for tracking testing
execution.
 testbed(s) and executing Test
All human resources, infrastructure equipment, and tools are available for setting20 up
Cntd…

7
 Cntd…
Conclusion
 Customers or end-users buy or adopt serviceability products or a system or solutions.
 Validating a software that is running on such system or products for its serviceability
is the primary requirement.
 Key components of Principles of Testing like Why to Test? What is Testing? What
to
Test? How to Test? are mostly well defined and understood.
 However, there are some lasting questions that keep supporting up in the mind of the
Readers, Testers, Leads, and Managers on concepts like Early Testing.
 Adoption of Early Testing as an integral activity of the overall Testing Schedule for
any given Software Project or a Release immensely benefits the Organization to
deliver a robust qualified Product or a System.
 The importance of Early Testing in your career? Feel free to share your thoughts
22
and
 Use Case Scenario
Testing
Generating Test Cases from Use Cases
 The verification of the correct implementation of use eases is a vital task in
software
development and quality assurance.
 Nowadays, use cases are a widely used technique to define the functional requirements
of
software systems.
 There are two main gaps in the generation of test cases from use cases: lack of automatism
and absence of empirical evaluation.
 The automatism of scenarios analysis written in natural language (first gap) has been
resolved using language patterns and regular expressions for extracting information from
use case templates.
 studies to measure and evaluate the effectiveness of scenario analysis 23
The main goal of empirical evaluation and its original contribution is the execution of
 Cntd
…
 The scenario analysis technique is a common technique for generating test cases from
use
cases.
 It identifies the scenarios from a use case and generates test cases from them.
 A use case is mainly defined by natural language and it is mainly composed
of steps.
 In Thus, the first task is to translate the behavior of a use case into a more
formal
model.
 An UML Activity diagram has been chosen to define the behavior of a use case.
 An Activity diagram allows indicating if an action is performed by the system or by
an
external action; it includes different execution flows. 24
Cntd
…

7
Cntd
…

7
 Cntd
 …
Then, use case scenarios are derived from the activity diagram.

 If the activity diagram has not got any loops, as in figure 1, the all-scenarios criterion

selects the paths that go through all output object-flow edges from decision nodes at

least once.

 If the activity diagram has got some loops, the all-scenarios criterion selects the paths

that go through all output object flow edges from decision nodes and all combinations

among loops at least once. .

 The numbers in each test case indicates the activities and decisions traversed from
the
activity 27
Cntd
…

52
 Cntd
…
 Test case generation, Test cases were generated over the activity diagram generated
from
each use case Scenario.

Table. Test cases

 Preform the testing activates and then recorded and report the Test case
53
result
End of chapter
Seven
Any
question???
54
End of Chapter
Four

Any question???

25