Chapter 3: Gathering user requirements

3.1. Putting together requirements gathering team

Requirements analysis is critical to the achievement of development project. Requirements

should be measurable, actionable, and testable and also should be related to the user’s
expectations. Requirement without any ambiguity fulfill the user’s requirement make project
successful. While gathering requirements focused on “what” should be required rather than
“how” it is required. “Using peer reviews, scenarios, and walkthroughs to validate and verify
requirements results in a more accurate, specification and higher customer satisfaction.”

It is estimated that 85% defects are find in requirements during software development. There are
some techniques that are used to gather requirement. Every technique is not used for every
project. In these techniques some are useful and some are not but it depends on the project’
description.

Requirements (Reqs) Gathering is the set of activities performed by a team, in collaboration with

their customer and users that transforms the wishes and needs of stakeholders into
actionable requirements for the design delivery and development phases.

Understanding user requirements is an integral part of information systems design and is critical
to the success of interactive systems. It is now widely understood that successful systems and
products begin with an understanding of the needs and requirements of the users.

Requirements team will be composed of SMEs (subject matter expert) who provide with detailed
information regarding the requirements, analysts, facilitator and scribe(s). To put together
requirements team, it is necessary to identify project stakeholders. A project stakeholder is
anyone who could be affected by the implementation of the new system. Project stakeholders
include:

 The direct users of the system

 The customer/payer of the system
 Anyone who will be affected by outputs the system produces
 Any internal or external users of the system whose needs must be addressed
  Anyone who will evaluate and bless the system when it is delivered and deployed
 Anyone who operated or support the system once it is in production

3.2. Fundamental requirements gathering techniques

User requirements can be gathered in different ways. The most common methods are:

 Interview with users

 Questionnaire
 Observation
 Business document analysis (work procedures, business forms, reports, etc)
 Brainstorming

The Interviews :- very common in either in the scope of system and software engineering.
The interview is origin for social science research. It is human based activity. The requirements
engineer has to be able to discuss with stakeholders or with future system users.

The interview has tree basic types; structured, semi-structured and un-structured. The most
valuable for the requirements definition is the un- structured interview. Contrastingly, un-
structured interview have to be held by some experienced engineer. The structured
interview commonly leads to missed some of important requirements. The set of questions is not
well prepared and structured. As well-working compromise; the semi structured interview,
where basic set of the question is prepared and used.

The questionnaires: - is probably the most important impersonal method. It is very useful in
preliminary requirements gathering. The questionnaires lack in discovering new facts or
dimensions of the proposed system. Therefore have to be prepared by an experienced
requirement engineer with huge knowledge of the problem domain. The task analysis; an
activity which is based on task decomposition. The top-level tasks are designed first and
then by top-down approach all sub-task are derivate and described.

The observation :- a method, which comes to system engineering from the ethnography and
other sociological research. The observation allows to observe users in their own
environment. This method is valid for human-centric system design. For observation are
valuable hidden cameras, with respect to privacy. Users very often change their behavioral, if
they are informed about observation.

The document analysis: - is a form of qualitative research in which documents are interpreted

by the researcher to give voice and meaning around an assessment topic. Analyzing
documents incorporates coding content into themes similar to how focus group or interview
transcripts are analyzed.

The brainstorming: - is very useful addition to the semi-structured interview. If there are more
then on stakeholders, the whole group is questioned in same time. The answers and discussions
of the all group are noticed. The laddering is a technique, which is used as part of the
brainstorming. It allows moderating the debate and brings hierarchical structures of the
stakeholder (or stakeholders) answers.

All developers should be adept at two fundamental requirements gathering techniques:

interviewing, and brainstorming.

Interview is one of the primary ways to gather information about an information system project.
People are interviewed about their work, the information they use to do their work, the type of
information processing that might supplement their work, etc.

Brainstorming is a technique where groups of people discuss a topic, and say anything that
comes to their minds about it. The rules are simple:

 All ideas are good; ideas are not judged by the group
 All ideas are owned by the group, not the individual
 All ideas immediately become public property, anybody is allowed to expand upon them.
What makes good requirement? Good requirements are complete, correct, feasible, necessary,
prioritized, unambiguous, and verifiable. In other words, they accurately describe what you have
been asked to build, they are realistic, they solve one or more needs within your organization,
and they can be demonstrably validated.

Functional and Non-functional Requirements

Functional requirements describe the behaviors of the system that support user goals, tasks or
activities. It is the functions or services of the system.

Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform.

Non-functional requirements are constraints and qualities of the system. Qualities are properties
or characteristics of the system that its stakeholders care about and hence will affect their degree
of satisfaction with the system. A constraint is a restriction on the degree of freedom you have in
providing a solution. Constraints can be economic, political, or environmental and pertain to
your project resources, schedule, target environment, or to the system itself. Constraints are not
subject to negotiation and, unlike qualities, are off-limits during design trade-offs.

Non-functional requirements may be classified in terms of qualities that a software must exhibit.
A more general classification distinguishes between product, process and external requirements.

Product requirements – the requirements that specify the delivered products must behave in a
particular way. E.g. execution speed, reliability, etc.

Process requirements – the requirements that are a consequence of organizational policies and
procedures. E.g. implementation requirement

External requirement – requirements which arise from factors which are external to the system
and its development process. E.g. interoperability
 Figure 1 Non-functional requirements

Another useful distinction is between the executing system and the work products that are
generated in its creation. In the case of the executing system, the qualities of interest are relative
to user goals and we refer to them as run-time qualities. In the case of the work products, the
qualities are driven by the development organization’s goals and we will refer to these as
development-time qualities. Development-time qualities are also called evolution qualities.

Run-time qualities include:

 usability(ease to use, learnable, memorability, efficiency, etc.)

 configurability and supportability
 correctness, reliability, availability
 quality of service requirements such as performance (throughput, response time, latency,
etc.)
 safety properties such as security and fault tolerance
 operational scalability including support for additional users or sites, or higher transaction
volumes
Development-time/evolution quality requirements are:

 localizability — ability to make adaptations due to regional differences

 modifiability or extensibility — ability to add future functionality
 evolvability — support for new capabilities or ability to exploit new technologies
 reusability — ability to reuse in future systems
 maintainability – ability to maintain the system
Non-functional requirements are written as follows:

TR34 The system shall be unavailable for no less than two minutes in a 24-hour period

TR78 A seminar search will occur within less than three seconds 95 percent of the time and no
more than ten seconds 99 percent of the time.

Non-function requirements are documented by including description, an example, a source,

references to related technical requirements, and revision history.
3.3. Essential Use Case Modeling

First adopted by Jacobson et al. (1992), use-case modeling is developed in the analysis phase of
the object-oriented system development life cycle. Use-case modeling is done in the early stages
of system development to help developers gain a clear understanding of the functional
requirement of the system, without worrying about how those requirements will be implemented.
A use-case is a representation of a discrete set of work performed by a use (or another system)
using the operational system (). A use-case model consists of actors and use cases. An actor is
an external entity that interacts with the system and a use case represents a sequence of related
actions initiated by an actor to accomplish a specific goal.

For identifying use cases, we recommend to ask the following questions:

 What are the main tasks performed by each actor?

 Will the actor read or update any information in the system?
 Will the actor have to inform the system about changes outside the system?
 Does the actor have to be informed about unexpected changes?

In UML, a use-case model is depicted in a use-case diagram that contains the use cases and
actors for a system. Begin working with the UML by modeling all scenarios in the system or
business with Use Case diagrams. Describe the system in terms of actors, which are external
agents that request a service from the system, and Use Cases. Each Use Case can be defined
simply by a textual statement that describes the scenario, or via other definitions, such as the
sequence of steps that are performed within the scenario, or the pre- and post-conditions of the
scenario.

3.4. Essential User Interface Modeling

The UI is the portion of software with which a user directly interacts. An essential UI prototype
is a low-fidelity model, or prototype, of the UI for your system. It represents the general ideas
behind the UI, but not the exact details.

Essential UI prototypes represent UI requirements in a technology-independent manner, just as

essential use case models do for behavioral requirements. An essential UI prototype is effectively
the initial state—the beginning point—of the UI prototype for your system. It models UI
requirements, requirements evolved through analysis and design to result in the final user
interface for your system.

Two basic differences exist between essential UI prototyping and traditional UI prototyping.
First, with essential UI modeling the goal is to focus on your users and their usage of the system,
not system features. This is one of the reasons you want to perform essential use case modeling
and essential UI prototyping in tandem: they each focus on usage. Second, your prototyping tools
are simple, including whiteboards, flip chart paper, and sticky notes. The minute you introduce
electronic technology to your prototyping efforts you have most likely made a design decision
about the implementation technology. If you use an HTML development tool to build a UI
prototype, then you may immediately narrow your design space to the functionality supported
within browsers. If you choose a Java development environment, then you may narrow your
design space to Java, and if you choose a Windows-based prototyping tool, you may narrow your
design space to whatever is supported on the Windows platform. Right now, you should be
focused on requirements, not design; therefore, you do not currently want to use technology-
based prototyping tools. Understand the problem first, and then solve it.
 Fig essential user interface prototype to enroll student in seminar

To create essential user interface, we typically through iterate the following tasks:

1. Explore the system usage. Your team will explore system usage via several means. First, you
will likely work together on a whiteboard to discuss ideas, work on initial drawing together, and
generally take advantage of the dynamic nature of whiteboards to come to an understanding
quickly of the portion of the system you are discussing. For example, with the university system,
you may gather around a whiteboard to make an initial drawing of what a university transcript
would contain or what a seminar enrollment submission would contain. Second, essential use
case modeling is an effective technique for understanding the behavioral requirements for your
system.

2. Model major user interface elements. Major UI elements, such as potential screens and
reports, can be modeled using flip chart paper. I say potential because whether something is a
screen or printed report is a design decision—a university transcript could be implemented as an
HTML page your users view in a browser, as a paper report printed and mailed to students, or as
an application screen. Each piece of flip chart paper is given a name, such as Student Transcript
or Seminar Enrollment Request, and has the appropriate minor UI elements added to it as
needed.

3. Model minor user interface elements. Minor UI elements, such as input fields, lists, and
containers that aggregate other minor UI elements are modeled using sticky notes. Notice how
each sticky note has a name that describes its purpose, but not how it is implemented. You can
look at the sticky note and immediately know how it is used. Different sizes of sticky notes are
used, indicating the relative size of each UI element.

4. Explore the usability of your user interface. Highly usable systems are learnable, they
enable user productivity, their use is easy to remember, and they are supportable.

5. Explore the relationships between user interface elements. The technique you employ is
user interface flow diagramming.

User interface flow diagram enables you to model the high-level relationship between major user
interface elements.

Fig user interface flow diagram

User Interface Prototyping

User interface prototyping is an iterative analysis technique in which users are actively involved
in the mocking-up of the UI for a system. UI prototyping has two purposes:

 First, it is an analysis technique because it enables you to explore the problem space your
system addresses.
 Second, UI prototyping enables you to explore the solution space of your system, at least
from the point-of-view of its users, and provides a vehicle for you to communicate the
possible UI design(s) of your system.

Four high-level steps are in the UI prototyping process:

 Determine the needs of your users

 Build the prototype
 Evaluate the prototype
 Determine if you are finished

Determine the needs of your users

User interface modeling moves from requirements definition into analysis at the point you decide
to evolve all or part of your essential user interface prototype into a traditional UI prototype. This
implies that you convert your hand drawings, flip-chart paper, and sticky notes into something a
little more substantial. You begin this process by making platform decisions. For example, do
you intend to deploy your system so it runs in an Internet browser, as an application with a
Windows-based graphical user interface (GUI), as a cross-platform Java application, or

as a mainframe-based set of “green screens”? Different platforms lead to different prototyping

tools, for a browser-based application, you need to use an HTML-development tool, whereas a
Java-based application would require a Java development tool and a different approach to the
user interface design.

As you iterate through UI prototyping, you discover you need to update your defined
requirements, including your use case model and your essential user interface prototype. You are
also likely to discover that information is missing from your domain model, a Class
Responsibility Collaborator (CRC) model, as well as from your conceptual model, a UML class
model. These models should be updated, as is appropriate, as you proceed with UI prototyping.
Remember, object-oriented software development is an iterative process, so this is normal.

Building the Prototype

Using a prototyping tool or high-level language, you develop the screens, pages, and reports
needed by your users. The best advice during this stage of the process is not to invest a lot of
time in making the code “good” because chances are high you will scrap large portions of your
prototype code when portions or all of your prototype fail the evaluation.

With the user interface platform selected, you can begin converting individual aspects of your
essential UI prototype into your traditional UI prototype. For example, with a browser-based
platform, your major UI elements become HTML pages whereas, with a Windows-based
platform, they would become windows or dialog boxes. Minor UI elements would become
buttons, list boxes, custom list boxes, radio buttons, and so on as appropriate.
 Fig An HTML page for enrolling in a seminar.

Evaluating the Prototype

After a version of the UI prototype is built, it needs to be evaluated by your SMEs to verify that
it meets their needs. You need to address three basic questions during an evaluation:

 What is good about the UI prototype?

 What is bad about the UI prototype?
 What is missing from the UI prototype?

Determining If You Are Finished

After evaluating the prototype, you may find you need to scrap parts of it, modify parts, and even
add brand-new parts. You want to stop the UI prototyping process when you find that the
evaluation process is no longer generating any new ideas or it is generating any new ideas or it is
generating a small number of not-so-important ideas. Otherwise, back to step one.

Exercise

1. Create a use case diagram for banking industry. Try to include as much services as possible
in the diagram. The whole business process including opening account, depositing money,
withdrawing, etc. should get the service from the new system. Then draw sequence diagrams
for each use case.
2. Create a use case diagram for library system. First, identify the functions that library provides
to its users. From that, develop the use case diagram to facilitate these services.
3. ABC supermarket sells different kinds of items to its customers. It keeps goods in stock
before putting them in the supermarket for sale. Create a use case diagram that helps the
supermarket to manage the stock. For all of your use cases, draw sequence diagrams.
4. A hospital treats patients for all kinds of disease. They store and keep patient information for
later use. Create a use case diagram that helps in treating patients by managing and
processing the data in a better way. Then model class diagram for the system. Finally create
sequence diagram for each use case.
Remark

The word I in this course refer to the author of the book used as textbook for the course. Hence,
all instances of the word I in handouts and slides should be replaced by the name of the author
“Scott W. Ambler”, the author of the book “The Object Primer”. They do not refer to the
instructor of the course in any sense.

3.5. Domain modeling with class responsibility collaborator (CRC) cards

Domain modeling is the task of discovering the classes that represent the things and concepts
pertinent to your problem space. For example, your domain model for a university would include
concepts such as student, instructor, professor, seminar, transcript, and registrar. The nouns and
noun phrases within your essential use case model are good candidates for concepts that should
be included in your domain model.
A CRC (Class Responsibility collaborator) model is a collection of standard index cards that
have been divided into three sections (see figure): class name, responsibilities, and collaborator.
A class represents a collection of similar objects, a responsibility is something that a class knows
or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities.

Class name

Responsibilities Collaborator

Figure 11 CRC card

A class represents a collection of similar objects. An object is a person, place, thing, event, or
concept that is relevant to the system at hand. For example in a university system, classes would
represent students, tenured professors, and seminars.

The name of the class appears across the top of a CRC card and is typically a singular noun or
singular noun phrase, such as “Student," "Tenured Professor," and “Seminar." You use singular
names because each class represents a generalized version of a singular object. The information
about a student describes a single person, not a group of people. Therefore, it makes sense to use
the name "Student" and not “Students." Class names should also be simple. For example, which
name is better: "Student" or “Person who takes seminars"?

A responsibility is anything that a class knows or does. For example, students have names,
addresses, and phone numbers. These are the things a student knows. Students also enroll in
seminars, drop seminars, and request transcripts. These are the things a student does. The things
a class knows and does constitute its responsibilities. A class is able to change the values of the
things it knows, but it is unable to change the values of what other classes know, in other words,
classes update their own attributes and nobody else's.

Sometimes a class has a responsibility to fulfill, but not have enough information to do it. For
example, students enroll in seminars. To do this, a student needs to know if a spot is available in
the seminar, and if so, he then needs to be added to the seminar. However, students only have
information about themselves not about seminars. What the student needs to do is
collaborate/interact with the card labeled "Seminar" to sign up for a seminar. Therefore,
"Seminar" is included in the list of collaborators of "Student."

Collaboration takes one of two forms: a request for information or a request to do something.
For example, the card "Student" requests an indication from the card "Seminar" whether space is
available, a request for information. Furthermore, "Student" then requests to be added to the
"Seminar" if a seat is available, a request to do something. Another way to perform this logic,
however, would have been to have "Student" simply request “Seminar" to enroll himself into
itself. Then have "Seminar" do the work of seeing if a seat is available and, if so, then enrolling
the student and, if not, then informing the student that he was not enrolled.

CRC models are effective tools for working with your users and SMEs while you are gathering
requirements, whereas UML class diagrams are a better choice for domain modeling during
analysis.
Student

ID
Name
Address
Seminar
Phone number
Enroll in a Seminar
Drop Seminar
Request transcripts

Figure 12 CRC with name, responsibilities, and collaborator

3.6. Developing a supplementary Specification

Supplementary requirements are all types of constraints and qualities related to the system as a
whole and not only to individual functions. For example, a supplementary requirement may
establish that the system must be compatible with a given legacy database, or be implemented
with a given programming language, or even follow a given look and feel.

Care must be taken when supplementary requirements are defined. A requirement such as “the
system must be easy to use” is not sufficiently clear. It would be better to say something like
“novice users must be able to complete tasks without errors on their first attempt.” That gives a
more precise idea of what must be designed to accomplish the requirement.

Nonfunctional and supplementary requirements may also be identified with different groups such
as, for example, interface, implementation, performance, fault tolerance, etc. The goal of making
such distinctions is to allow for better organization.

3.7. Identifying Change Cases

A change is a requirements-level expression of an intended revision. A change may be very
specific, such as changing from 9.6 Kb modems to 28.8 Kb modems, or it may represent a
simply stated intention to make a revision that will have broad scope, such as amending the
business model to enable employees to telecommute and work from home. Thus, depending on
the narrowness of its focus, a change may require amending one or many use cases, expressed as
change cases which describe the intended, revised function.

A change case consists of: (a) a use case, with a new or revised scenario, derived from a change
to requirements, and (b) a set of existing use cases, that would need to be changed to be
consistent with the changed requirements. Our description of change comprises the description
of the change (intentional) and an associated set of change cases, each describing a potential,
new or revised use case. Each change case, in turn, has a relationship to the use cases that would
by affected by the change case. We thus provide traceability as advocated by Jacobson [Jacobson
92] at two levels: from the change to representative change cases, and from each change case to
the affected use cases (the Impact Links). These components and their relationships are shown in
Figure 1.
Figure 1. Change, Change Cases and Use Cases