Chapter 3

User Requirements and Gathering

 Gathering User Requirements
Requirement: Statement of what the system must do or what characteristic it must
have.
Requirements are capabilities and conditions to which the system and
more broadly, the project must conform.
During Analysis, Requirements are:
 Written from business person perspectives
 Focused on “what ” the system and business user need.
 So, are usually called business user requirements or sometimes user
requirements.
 Cont.
During Design, Requirements are:
 Written from developer perspectives
 Focused on “how” the system will be implemented (business
requirements(during analysis) evolve to become more technical).
 Are usually called system requirements.

Requirements in nature can be:

 Functional or Nonfunctional, are called requirement concepts
elicitation
 Requirement Elicitation
 Focuses on describing the purpose of the system.
 Requirement elicitation and analysis are only focus on user’s view of
system:
 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. (Functional Requirement)

 The system structure, the implementation technology selected to build the system, the
system design, the development methodology, and other aspects not directly visible to

the user are not part of the requirements. (Nonfunctional Requirement)

 Requirement Elicitation Concepts

Functional Requirements:
 Directly related to a process the system has to perform or
information it needs to contain.
 Describe the interactions between the system and its environment
(includes user and any other external system) independent of its
implementation.
 Cont.
 Flow directly into the next steps of analysis (functional, structural, and
behavioral models) because they define the functions that the system
needs to have.
 E.g. of FR for Inventory system: The system must able to:
 Search available inventory.
 Report actual and budget expense.
 Cont.

Non Functional Requirements:

 Describe aspects of the system that are not directly related to the
functional behavior of the system.
 Refers to behavioral properties that the system must have, such as
performance and usability.
 Primarily used in design when decisions are made about UI, HW, SW,
and the system’s underlying physical architecture.
 Cont.
 Describes system characteristics : operational, performance, security,
cultural and political which are not describe business processes or
information, but they are very important in understanding what the final
system should be like. For instance:
 Supportability: ease of change after deployment, i.e. adaptability,
maintainability.
 Performance (response time, availability, accuracy.
 Usability: ease of learn to operate, prepare input, interpret output.
 Requirement Elicitation Activities
 Identifying Actor: 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.
 Identifying Use Case: Once developers and users agree on a set of
scenarios, developers derive from the scenarios a set of use cases that
completely represent the future system. When describing use cases,
developers determine the scope of the system.
 Requirement Elicitation Activities cont’d…

 Refining Use Case: During this activity, developers ensure that the
requirements specification is complete by detailing each use case and
describing the behavior of the system in the presence of errors and exceptional
conditions.
 Identifying Use Case Relationships (use case dependency for
requirement specification consistency)
 Identifying Nonfunctional Requirements (performance, resource,
documentation, quality, security)
 Cont.
 During requirements elicitation, developers access many different
sources of information,(including client-supplied documents, manuals
and technical documentation, users and clients themselves.
 To elicit information for making decision with users and clients and
managing dependencies among requirement and artifacts, two
eliciting methods were focused:
 Joint Application Design (JAD)
 Traceability
 Fundamental Requirement Gathering Techniques

 Before determining the requirement, it is better to have clear vision of

kind of system to be developed and level of change it will bring to the
organization.
 The basic analysis process is divided in to three:
I. Understanding current system
II. Identifying improvements
III. Developing requirements for the new system.
 Cont.

5 most commonly used requirement gathering techniques:

i. Interviews
ii. JAD Sessions (a special type of group meeting)
iii. Questionnaires
iv. Document Analysis
v. Observation
 Cont.

i. Interviews
 The most commonly used.
 In general conducted one-on-one (1interviewer(asker),1interviwee
(responder)), but due to time constraint several people can be
interviewed at a time.
 Cont.

5 steps of interview process:

1. Selecting Interviewees (create an interview schedule that lists all interviewee)
2. Designing Interview Questions (close-end, open-end)
3. Preparing for the Interview (list of question to be asked)
4. Conducting the Interview (record interviewee info)
5. Post-interview Follow-up (prepare interview report in 48 hr. b/c may forget)
 Cont.
I
Schedule

I
Question

I Report
 Users Requirement Modeling

I. Use Case Modeling: better and functional task

II. Domain Modeling: business domain concepts
III. Interface Prototyping: screen, pages and reports
 Cont.

I. Use Case Modeling

 An important goal of requirements modeling is to come to an
understanding of the business problem that the system is to address
in order to understand its usage requirements.
 Use case model emphasizes use case diagrams which are one UML
standards.
 Cont.

Use Case Diagram: depicts:

 Actors: person, organization, or external system that plays a role in
one or more interactions with the system.
 Drawn as stick figures
 Use Case: sequence of actions that provide something of measurable
value to an actor
 Drawn as a horizontal ellipse
 Cont.

 Association: modeled as lines connecting use cases and actors to

one another.
 The arrowhead is often used to indicate the direction of the initial
invocation of the relationship and/or to indicate the primary actor
within the use case.
 Boundary (System Boundary Box): indicate scope of the system.
 Drawn as rectangle around the use case.
 Rarely used.
 Anything within the box represents functionality that is in scope, not out of the box.
 Cont.

Fig 3.2: Use Case diagram for University

 Cont.

Use Case Description:

Name: use case name
Pre condition: condition to be fulfilled first
Post condition: condition resulted finally
Basic course of action: logically arranged action performed
Use Case Scenario: description of a potential business situation that
may be faced by the users of a system
 Users Requirement Modeling Cont.

II. Domain Modeling

 Modeling based on business concepts.
Domain Modeling with Class Responsibility Collaborator (CRC) Cards
 is a collection of standard index cards that have been divided into
three sections:
i. Class: collection of similar objects
ii. Responsibility: something that a class knows or does
iii. Collaborator: another class that a class interacts with to fulfill its
responsibilities
 Users Requirement Modeling Cont.

For instance: Student enrollment CRC

 Students have name, Phone no, address: Known
 Student enroll and drop seminars, request transcript: what does
 To enroll in the seminar, a student needs to know whether a spot is
available in the seminar, if so, needed to added to seminar. NB:
students only have information about themselves not seminars.
collaborate/interact with the card labeled Seminar to sign up for a
seminar. Therefore, Seminar is included in the list of collaborators of
Student.
 Users Requirement Modeling Cont.
Student
Student number Seminar
Name
Address
Phone number
Enroll in a seminar
Drop a seminar
Request transcripts

Table 1: CRC for student enrollment

 User Interface Prototyping

 UI is the portion of software with which a user directly interacts.

 Essential UI prototypes represent UI requirements in a technology-
independent manner, just as essential use case models do for
behavioral requirements.
 It models UI requirements, requirements evolved through analysis and
design to result in the final user interface for your system.
 Cont.

 Major UI element represents a large-grained item, potentially a

screen, HTML page, or report but,
 minor UI element represents a small-grained item, widgets such as
user input fields, menu items, lists, or static text fields such as labels.
 Cont.

 When team is creating essential UI prototype, it iterates between the

following tasks:
a. Explore system usage
b. Model major UI elements
c. Model minor UI elements
d. Explore the usability of UI (learnable, supportable, easy to remember)
 Chapter 4

User requirement validation

 Cont.

 verification is ensuring requirement are correct, consistent, complete

and accurate.
 Used in determining the right requirements, while verification
determines that implementation is correct with respect to its
requirements.
 Cont.

The main objective of validation is to certify that requirement

specification document is acceptable description of the system, which is
going to be implemented.
I. Testing Early and Often

 Catching defects as early as possible is the least expensive way to

ensure software quality.

 You should test the phase in the case of system developments

through out the time.
 Cont.

 By often testing, your team and stakeholders can remain aware of

the current state of the code and make informed decisions throughout
the project.

 Ultimately, you should be able to answer the question "Can we

release?" and understand the implications for the people who use the
software.
 Cont.

II. Use Case Scenario Testing

 To test your requirement models you can apply one or more of the
following techniques:

 Use Case Scenario Testing

 User Interface Walkthrough

 Requirement Reviews
 Cont.

Use Case Scenario Testing:

 Used to test domain models, if it accurately reflects the aspects of the

business that you are modeling.

 Steps of testing process:

i. Perform domain modeling

ii. Create the use case scenarios

iii. Assign classes to your SMEs (Subject Matter Experts)

 Cont.

iv. Describe how to act out a scenario

v. Act out the scenarios

vi. Update the domain model

vii. Save the Scenarios

 Cont.

Create Use Case Scenario

 Describes a single path of logic through one or more use cases.

 When you describe a use case scenario, you want to give it a name
and short description and then a description of the steps to take to
fulfill the scenario.

 Consider tasks the system should and shouldn’t be able to handle

 Explore business rules

 Do some more brainstorming

 Cont.

Acting out Use Case Scenario : Steps:

i. Call out a new scenario

ii. Determine which card should handle the responsibility

iii. Update the cards whenever necessary

iv. Describe the processing logic

v. Collaborate if necessary

vi. Pass the ball back when done

 Cont.

Advantages of Use Case Scenario Testing

 Accomplished provides you with a detailed

 Developers are often descriptions of the business skeptical logic of

the system

 Simple and it works

 Scenarios help to define how people interact with the system.

 Cont.

Disadvantages of Use Case Scenario Testing: 3 Serios Problems:

 Other approaches are better for testing early, unstable code.

 Are not designed for coverage of the program.

 Are often heavily documented and used time again.

 Group Assignment(10%)

1.How are Use Cases Used?

2.What is software process in oosad?
3.Discus system development life cycle.
4.Discus the difference b/n OOA and OOD.
5.Define Requirements and mention its types.

Submission date: Dec 14