SENG304: Software

Requirement
Engineering and
Construction
LECTURE THREE: SOFTWARE
REQUIREMENT ELICITATION I
Preparing for Requirements
Elicitation
 Develop The Product Mission Statement
 The first thing we need to do when undertaking the development of a new
system, or redesign of an old one is to obtain or develop a concise description
of what it is supposed to do.
 Such a statement is often called a product mission statement (or system
mission statement).
 Some organizations refer to a concept of operations statement, which is
similar to the mission statement, though it tends to be longer.
Preparing for Requirements
Elicitation
 The product mission statement acts as a focal point for all involved in the
system,
 It allows us to weigh the importance of various features by asking, “How
does that functionality serve its intent?”
 A product mission statement should be brief, descriptive, compelling, and
never detailed.
 For the baggage handling system, we may have something like - To automate
all aspects of baggage handling from passenger origin to destination.
Preparing for Requirements
Elicitation
 For the pet store POS system, consider - To automate all aspects of customer
purchase interaction and inventory control.
Preparing for Requirements
Elicitation
 Identify the System Boundaries
 The system boundary is a conceptual line that divides a system from
‘everything else’.
 They can be physical, logical, temporal, spatial, functional, or conceptual,
depending on the purpose and perspective of the analysis.
 Physical boundary of a computer system defines its hardware components,
such as the CPU, memory, disk, keyboard, mouse, and monitor, as well as
their connections and interactions.
Preparing for Requirements
Elicitation
 Logical boundary of a software system outlines its software components,
such as modules, classes, functions, variables, and data structures
 Temporal boundary of a system specifies its phases, milestones, tasks, and
deadlines
 Spatial boundary of a system include the geographic differences among
team members (different cities).
 Functional boundary of a system outlines its activities and roles.
 Conceptual boundary of a system includes its actors and norms
Preparing for Requirements
Elicitation
 System boundaries help to define the scope, context, and interfaces of a
system, as well as its inputs, outputs, and feedback loops.
 System boundaries are not fixed or absolute, but rather flexible and relative,
depending on the level of abstraction, the stakeholder needs, and the system
goals.
 It is useful to think of a system’s boundary as being made up of those things
that are part and not part of the system, things that can either affect the
system or be affected by it.
Preparing for Requirements
Elicitation
 Knowing the system boundaries will help to identify the set of people and
entities involved with the system and define their interaction with the system
(this could be direct or indirect interaction)
 Without defining the system boundaries correctly, it is possible that important
stakeholders will be overlooked—a potentially disastrous situation.
Preparing for Requirements
Elicitation
 Develop Context Diagrams
 A context diagram is a visual
representation diagram for a
system of interest showing system
boundaries and interactions with
other systems, people, and the
environment.

A Context Diagram for Online Community

Preparing for Requirements
Elicitation
 The context diagram is important for two reasons.
 First, it provides a basis for dialog about the system for engineers and
stakeholders, throughout the project lifecycle.
 Second, the context diagram helps combat scope creep, that is, the
unchecked growth of functional requirements beyond the intent of the
system.
 The context diagram can also assist in requirements agreement and analysis
when discussing ambiguous, complex, and missing requirements.
Preparing for Requirements
Elicitation
 Identify the System Stakeholders
 Stakeholders represent the set of individuals who have some interest (a stake)
in the success (or failure) of the system.
 For any system, there are many types of stakeholders, both obvious and
sublime. The most obvious stakeholder of a system is the user.
 The user is defined as the class (consisting of one or more persons) who will
use the system.
Preparing for Requirements
Elicitation
 The customer is the class (consisting of one or more persons) who is
commissioning the construction of the system.
 Sometimes the customer is called the client (usually in the case of software
systems) or sponsor (in the case where the system is being built not for sale,
but for internal use).
 But in many cases the terms “customer,” “client,” and “sponsor” are used
interchange ably depending on the context.
Preparing for Requirements
Elicitation
 Note that the sponsor and customer can be the same person.
 Clients, Customers, Users, Sponsors - however you wish to redefine these
terms, are all stakeholders because they have a vested interest in the system.
 Other examples of stakeholder -
 Customers (clients, users)
 The customers’ customers (in the case of a system that will be used by third
parties)
Preparing for Requirements
Elicitation
 Sponsors (those who have commissioned and/or will pay for the system)
 All responsible engineering and technical persons (e.g., systems,
development, test, maintenance)
 Regulators (typically, government agencies at various levels)
 Third parties who have an interest in the system but no direct regulatory
authority (e.g., standards organizations, user groups)
 Society (is the system safe?)
 Environment (for physical systems)
Preparing for Requirements
Elicitation
 Negative Stakeholders
 Negative stakeholders are those who may be adversely affected by the
system. These include competitors, and people whose jobs will be changed,
adversely affected, or displaced by the system.
 There are also internal negative stakeholders - other departments who will
take on more workload, jealous rivals, skeptical man, and more.
 These internal negative stakeholders can provide passive-aggressive
resistance and create political nightmares for all involved.
Preparing for Requirements
Elicitation
 All negative stakeholders have to be recognized and accounted for as much as
possible.
 There are always individuals who are not directly affected by systems, who
are nonetheless interested in or opposed to those systems, and because they
may wield some power or influence, they must be considered.
 These parties include environmentalists, single-issue zealots, advocates of all
types, the self-interested, and so on.
Preparing for Requirements
Elicitation
 Some people call these kinds of individuals “gadflies” and they shouldn’t be
ignored.
 Stakeholder Questions - One way to help identify stakeholders is by
answering the following set of questions -
 Who is paying for the system?
 Who is going to use the system?
 Who is going to judge the fitness of the system for use?
 What agencies (government) and entities (nongovernment) regulate any
aspect of the system?
Preparing for Requirements
Elicitation
 What laws govern the construction, deployment, and operation of the
system?
 Who is involved in any aspect of the specification, design, construction,
testing, maintenance, and retirement of the system?
 Who will be negatively affected if the system is built?
 Who else cares if this system exists or doesn’t exist?
 Who have we left out?
Preparing for Requirements
Elicitation
 Rich Pictures - In some systems the complete set of stakeholders is not
easily determined, even with the identifying stakeholder questions.
 This situation is sometimes the case with novel systems where there is no use
history nor impact analysis to inform the identification of stakeholders.
 In these situations a more holistic systems-based approach may be
appropriate. One of such approach is the use of a cartoonlike drawing called
a “rich picture”
Preparing for Requirements
Elicitation
 Rich picture shows
various users along with
their goals, wants, and
needs.
 Rich pictures resemble
annotated use-case
diagrams or concept
maps, but they are rather
informal.
Rich picture for the pet store point of sales system
Preparing for Requirements
Elicitation
 Stakeholder/User Classes
 Once the stakeholder (including user) groups have been identified, it may be
necessary to divide these groups into classes to adequately address their
needs and desires.
 For each of these classes and subclasses, we need to select a champion or
representative sample of the group to interact with during requirements
elicitation
Preparing for Requirements
Elicitation
 One approach could be to select a single representative for the group. Such an
approach would work well when the class is relatively small and uniform in
composition.
 Another strategy would be to select a small subset of the class. Such an
approach would apply when the class is large but we don’t want to rely on a
single person to represent the class.
Preparing for Requirements
Elicitation
 We can group users into a number of distinct user classes based on these sorts
of differences:
 Their access privilege or security levels (such as ordinary user, guest user,
administrator)
 The tasks they perform during their business operations
 The features they use
 The frequency with which they use the product
 Their application domain experience and computer systems expertise
Preparing for Requirements
Elicitation
 The platforms they will be using (desktop PCs, laptop PCs, tablets,
smartphones, specialized devices)
 A better way to identify user classes is to think about the tasks that various
users will perform with the system
 User class for a banking system therefore might include teller, loan officer,
customer care officer, and branch manager
 Note:
 Certain user classes could be more important than others for a specific
project. User class will have its own set of requirements for the tasks that
members of the class must perform
Preparing for Requirements
Elicitation
 There could be some overlap between the needs of different user classes
 For instance, Tellers, Customer Care Office, and loan officers all might have
to check a bank customer’s account balance
 Different user classes also could have different quality expectations, such as
usability, that will drive user interface design choices.
Preparing for Requirements
Elicitation
 Identifying user classes
 Identify and characterize the different user classes early in the project so you
can elicit requirements from representatives of each important class.
 A useful technique for this is a collaboration pattern, which involves -
 Start by asking the project sponsor who he expects to use the system.
 Brainstorm with as many user classes as you can think of, do not overlook
a user class, which can lead to problems later when someone complains
that the delivered solution doesn’t meet her needs.
Preparing for Requirements
Elicitation
 Start by asking the project sponsor who he expects to use the system.
 Brainstorm with as many user classes as you can think of, do not overlook
a user class, which can lead to problems later when someone complains
that the delivered solution doesn’t meet her needs.
 Look for groups with similar needs that you can either combine or treat as
a major user class with several sub-classes
 Try to have fewer distinct user classes
 While identifying user classes we need to perform stakeholder and user
analysis, by studying the organization chart to look for:
 Departments that participate in the business process.
Preparing for Requirements
Elicitation
 Departments that are affected by the business process.
 Departments or role names in which either direct or indirect users might be
found
 Note:
 Organization chart analysis reduces the likelihood that you will
overlook an important class of users within that organization.
 It shows where to seek potential representatives for specific user
classes, as well as helping determine who the key requirements
decision makers might be.
Preparing for Requirements
Elicitation
 Studying the organization chart helps you judge how many user
representatives you’ll need to work with to feel confident that you
thoroughly understand the broad user community’s needs
 Also try to understand what type of information the users from each
department might supply based on their role in the organization and
their department’s perspective on the project
 Document the user classes and their characteristics, responsibilities, and
physical locations in the software requirements specification (SRS) or
in a requirements plan for your project.
Preparing for Requirements
Elicitation
 Choose a User Persona
 A persona is a ­description of a hypothetical, generic person who serves as a
stand-in for a group of users having similar characteristics and needs
 You can use personas to help you understand the requirements and to design
the user experience to best meet the needs of specific user communities
 Make sure the personas you create truly are ­representative of their user class,
based on market, demographic, and ethnographic research
Preparing for Requirements
Elicitation
 Choose a Product Champion
 A product champion is someone who sees value in a product, creates and
develops the product in a systematic fashion
 Each product champion serves as the primary interface between members of a
single user class and the project’s business analyst.
 The champions is actual users, not surrogates such as funding sponsors,
marketing staff, user managers, or software.
Preparing for Requirements
Elicitation
 Product champions gather requirements from other members of the user
classes they represent and reconcile inconsistencies.
 Listed below are some of the qualities of a product champion
 Product champions should have a clear vision of the new system
 Product champions should be enthusiastic about the development of the
new system
 Champions should be effective communicators who are respected by their
colleagues
 Product champions should have a good understanding of the application
domain and the solution’s operating environment.
Preparing for Requirements
Elicitation
 Below are some of the responsibilities of a product champion under different
categories-
 Planning
 Refine the scope and limitations of the product.
 Identify other systems with which to interact.
 Evaluate the impact of the new system on business operations.
 Define a transition path from current applications or manual operations.
Preparing for Requirements
Elicitation
 Requirement Gathering
 Collect input on requirements from other users.
 Develop usage scenarios, use cases, and user stories.
 Resolve conflicts between proposed requirements within the user class.
 Define implementation priorities.
 Provide input regarding performance and other quality requirements.
Preparing for Requirements
Elicitation
 Requirement Gathering
 Evaluate prototypes.
 Work with other decision makers to resolve conflicts among requirements from
different stakeholders.
 Validation and verification
 Review requirements specifications.
 Define acceptance criteria.
 Develop user acceptance tests from usage scenarios.
 Provide test data sets from the business.
 Perform beta testing or user acceptance testing.
Preparing for Requirements
Elicitation
 User Aids
 Write portions of user documentation and help text.
 Contribute to training materials or tutorials.
 Demonstrate the system to peers.

 Change management
 Evaluate and prioritize defect corrections and enhancement requests.
 Dynamically adjust the scope of future releases or iterations.
 Evaluate the impact of proposed changes on users and business processes.
 Participate in making change decisions.
Preparing for Requirements
Elicitation
 Stakeholder Prioritization
 Not all stakeholders are of equal importance.
 We have many stakeholders and some of their needs and desires may conflict, we
rank or prioritize the stakeholder classes to help resolve these situations.
 Usually rank denotes the risk of not satisfying the stakeholder e.g., legal
requirements should be no. 1 unless you want to go to jail.
 Ranking the stakeholders will lead to requirements prioritization, which is the key to
reconciliation and risk mitigation.
Preparing for Requirements
Elicitation
 These table contains Stakeholder Class Rank Rationale
a partial list of Cashiers 2 They have the most interaction with the system.
stakeholders for the Managers 1 They are the primary customer/sponsor
pet store POS system System maintenance 4 They have to fix things when they break.
ranked using ratings personnel
Store customers 3 They are the most likely to be adversely affected.
1 through 6, where 1
Inventory/warehouse 6 They have the least direct interaction with the
represents the highest personnel system.
importance or Accountants/sales 5 They read the reports
personnel
priority.
Preparing for Requirements
Elicitation
 Stakeholder Negotiations
 It is inevitable that along the way the requirements engineer must negotiate with
customers and other stakeholders.
 Often the negotiations deal with convincing the customer that some desired
functionality is impossible or too costly.
 And expectation setting and management throughout the life cycle of any system
project is an exercise in negotiation.
Preparing for Requirements
Elicitation
 Some simple principles that should be remembered in managing negotiation
include –
 Set the ground rules up front - When a negotiation is imminent, make sure
that the scope and duration of the discussions are agreed. If there are to be
third parties present, make sure that this is understood. If certain rules need
to be followed, make both parties aware. Trying to eliminate unwanted
surprises for both sides in the negotiation will lead to success.
Preparing for Requirements
Elicitation
 Understand people’s expectations - Make sure you realize that what matters
to you might not matter to the other party. Some people care about money;
others care more about their image, reputation, or feelings. When dealing
with negotiations surrounding system functionality, understand what is
most important to the customer. Ranking requirements will be most helpful
in this regard.
 Look for early successes - It always helps to build positive momentum if
agreement, even on something small, can be reached. Fighting early about
the most contentious issues will amplify any bad feelings and make
agreement on those small issues more difficult later.
Preparing for Requirements
Elicitation
 Be sure to give a little and push back a little - If you give a little in the
negotiation, it always demonstrates good faith. But the value of pushing
back in a negotiation is somewhat counterintuitive. It turns out that by not
pushing back, you leave the other party feeling cheated and empty.
 Conclude negotiating only when all parties are satisfied - Never end a
negotiation with open questions or bad feelings. Everyone needs to feel
satisfied and whole at the end of a negotiation. If you do not ensure mutual
satisfaction, you will likely not do business together again, and your
reputation at large may be damaged (customers talk to one another).