Internal Process Guidelines
SUBJECT:
Requirements
REVISED:
Click here to enter a date.
APPLIES TO:
ITS Iterative Framework
ISSUED:
4/30/2010
ISSUED BY:
Process & Service Management
ATTACHMENT(S):
N/A
Description
The ITS Iterative Design and Development (ITS Iterative) Framework requirements are like other requirements. They define what
solution the team is building, for whom, and why. The difference with the ITS Iterative approach is that the requirements are
developed and elaborated iteratively so that not all the requirements are necessary to start development.
User-centered design practices, while not exclusive to ITS Iterative, compliment ITS Iterative development because they call for
collaboration with the stakeholder and users to understand actual user goals. Design solutions focus on helping users accomplish
those goals instead of detailing speculative features that may consume budget but are rarely used once deployed. Exposing users
and stakeholders to the design early can help the team expose design flaws and hidden opportunities before they are coded.
User-centered design artifacts such as persona maps, screen mock ups, and storyboards communicate the design to stakeholders,
users, and the entire development team. Story cards are developed from these artifacts to express business value as assignable work
packages. The story cards become the currency of the project and represent the business value the stakeholder wants to develop,
although not all of the story cards may be developed as time and budget constrain. These artifacts are ideally visible at all times, in a
common team space, to facilitate conversation among team members.
Requirements: Elicit and Gather
Activities
Interviews
Interviews are face-to-face meetings with stakeholders. The interviewer asks questions to collect information about stakeholder
needs. Interviews identify a wide range of requirements topics such as business goals and priorities, stakeholder tasks and data
requirements, and the environment in which business processes are executed. Interviews probe what a business process should be
after the project is successfully completed. Interviews also help identify additional sources of requirements information.
Prepare open-ended, non-specific questions when planning the interview; for instance, “What do you like about your job?” rather
than, “Should we put this button here?” The interviewer’s goal is to engage users in a conversation about their work, not simply read
off a list of questions.
Specific steps:
 Identify the stakeholders to interview.
 Arrange the interview.
 Conduct the interview.
 Debrief with the rest of the project team.
 Document the results.
Maintained by Knowledge Support
Page 1 of 5
ITS
Iterative Framework IPG
Requirements
Direct Observation
Observation is the activity of watching stakeholders perform their jobs in the workplace in order to understand how software will be
used in its work context. Observations define ‘As Is’ business processes and uncover details (workarounds, solved problems) that
might not be obvious when stakeholders describe tasks and activities that are often second-nature to them.
Direct observation is not necessarily the same as an interview. The interview focuses on conversation, while the direct observation
focuses on observation. Reserve questions that come up during the direct observation for a later time. When a user begins
answering questions, the intimacy of direct observation is lost because a formal mode of communication takes over.
Specific steps:
 Identify the users to observe.
 Arrange the observation.
 Conduct the observation.
 Analyze and document the observations.
Requirements: Analyze
Tools
Persona
According to advanced agile practitioner and author Scott W. Ambler, “A persona . . . defines an archetypical user of a system, an
example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to
be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross Williams. In other words,
personas represent fictitious people which are based on your knowledge of real users.”
Ambler continues, “Unlike actors, personas are not roles which people play. In use case modeling actors represent the roles that
users, and even other systems, can take with respect to your system. For example, in a banking application we would have actors
such as Customer and Credit Card Processor. Actors are often documented by a sentence or two describing the role. For example the
description for Customer might read ‘A person or organization which does business with the bank.’
Personas are different because they describe an archetypical instance of an actor. In a use case model we would have a Customer
actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.
It is quite common to see a page or two of documentation written for each persona. The goal is to bring your users to life by
developing personas with real names, personalities, motivations, and often even a photo. In other words, a good persona is highly
personalized.”
See example.
Persona Map
A persona map focuses the project team on specific users rather than every possible user. Use it to prioritize personas into tiers in
order to later focus development and design efforts.
It is a common assumption that if a team is using a persona map, the design is for only one user group, or rather, a primary persona.
This is not the case. The persona map allows for design for all persona tiers. Its purpose is to guide design decisions so that when a
feature is designed for one tier in the persona map, the goals and experiences of higher tiers are not violated. For example, when
designing for a tier 2 persona, features or functions that would violate the goals and user experiences of the tier 1 persona might not
be incorporated. The persona map is in this way used by the design team (and larger project team) to describe—and keep front and
center—the user(s) for whom the system will be built.
The persona map is particularly useful because raw user data is not inherently helpful and user-centered design is not intuitive. The
persona map provides the project team with a simple, fun tool for organizing and prioritizing raw data gathered during interviews
Maintained by Knowledge Support
Page 2 of 5
ITS
Iterative Framework IPG
Requirements
and observations. It also allows the project sponsors and stakeholders to have a hand in limiting scope early on in the project,
thereby setting expectations for the full project lifecycle.
Specific steps:
 Create a group of user personas based on user research. It is a good idea to include stakeholders who have goals related to
the project but may not directly use the product; for example, the sponsor.
 Have project stakeholders prioritize personas by breaking them into three tiers. Limit the number of personas included in
each tier to:
o
Tier 1: one persona
o
Tier 2: two personas
o
Tier 3: three personas
 Visually represent the tiers by physically placing the personas in their respective tiers. Reference the resulting artifact throughout
the development cycle to justify scope, resolve goal conflicts, and focus design decisions.
See example.
User Goal Diagram
The user goal diagram is a tool for analyzing the various goals that are relevant to a project.
Complete a user goal diagram when there is a need to illustrate synergy or conflict among user goals, when a visual tool would help
to identify relevant goals before findings are summarized and reported, or to identify priority goals for crafting a vision statement.
The user goal diagram can also serve as a rudimentary prioritization tool for identifying shared goals among users/user groups and
highlighting narrow goals with limited business value. The user goal diagram is most useful when pursued after completing the
persona map. The tool can be re-used at increasing levels of detail throughout the project’s lifecycle.
In complex projects, the user goal diagram defines and justifies scope decisions and reinforces a shared understanding of goals.
The user goal diagram’s usefulness can be prolonged by including success criteria for each goal. However, this additional step is not
required.
Specific steps:
 After completing the persona map, create a document listing all the persona map actors and their goals.
 Indicate each actor’s goals as well as those other goals that, based on their persona, they would support.
 Notice that some goals connect only to a single user. This may indicate an edge-case goal, depending on the priority or tier of
the user concerned. Other goals will connect to multiple users, indicating a higher business value.
See example.
Conceptual Object Model
The object model describes the entities or objects in the system and the relationships between them. It does not include specific
attributes or table properties. The object model informs the data model and must be as complete as possible prior to beginning
database and/or application development.
See example.
Maintained by Knowledge Support
Page 3 of 5
ITS
Iterative Framework IPG
Requirements
Data Model
A data model documents the informational needs of the system. It lists the data attributes needed to satisfy functional
requirements. A data model will also portray the logical structure of data independent of the data design or data storage
mechanism. It is the basis for designing the physical data structures (tables and rows) of the system. A data model summarizes
information needs into groups that eliminate redundant or complex data structures and promote efficient system design. The data
model is created and updated over multiple iterations as development progresses.
See example.
Requirements: Design (User Centered)
Techniques (Terms and Definitions)
Workflow Diagram
Workflow diagrams are both a concept and a practical tool. A workflow diagram uses flow diagramming techniques to illustrate
directed flows between processing steps. Workflow diagrams provide a means to expose waste and eliminate steps that do not
deliver business value. For example, the diagram can expose excessive queuing or bottlenecks.
Single processing steps or components of a workflow diagram can be defined by three parameters:
 Input description—information required to complete the step
 Transformation rules—algorithms applied to the input by system and/or user
 Output description—information produced by the step and provided as input to downstream steps
See example.
Thin Slicing
Thin slicing is a design practice where a business process supporting user goals is broken down by both breadth and depth. The most
valuable components are elaborated, developed, and deployed before every case and edge case is, if ever, addressed. For example,
Figure 1 below represents the path a user would take to accomplish their goal of going from Point A to Point B.
Path to completion
A
Most Likely
(Happy Path)
Least Likely
(Edge Cases)
B
Scenario 1, satisfies most use cases for most users
Scenario 10, satisfies use cases for some users’ infrequent goals
Figure 1
Maintained by Knowledge Support
Page 4 of 5
ITS
Iterative Framework IPG
Requirements
The development team would focus on defining requirements for developing Scenario 1 long before Scenario 10. The sponsor
may eventually decide that Scenario 10 is not worth the remaining budget; thus, requirements would not be developed for
Scenario 10. Meanwhile, the team has already delivered the business value of Scenario 1.
A basic example of the concept of thin slicing might be the addition of a date field to a web form. Scenario 1 might be the
addition of a string field labeled “Date.” Scenario 2 could then be adding validation to the date field to enforce the format of
DD/MM/YYYY. Scenario 3 could be to include validation that ensures that no date before 1900 can be entered. Other scenarios
would follow as relevant.
In Figure 2, the development team could further break down scenarios into features prioritized by business value:
Scenario 1
Feature 1
Feature 2
Feature 3
Figure 2
If Feature 3 will provide more business value, Feature 3 may be developed first. Features 1 and 2 may be satisfied with a process
outside the system until they become a priority.
Tools
Storyboard
Storyboards graphically organize a series of functions derived from user stories, mockups, use cases, and the like. They are displayed
in sequence to assist in visualizing the chronological interactions between users and systems.
The team places ideas on storyboards and then arranges them on the wall. This process of visual thinking and planning stimulates
group brainstorming, which fosters more ideas and generates group consensus.
See example.
Maintained by Knowledge Support
Page 5 of 5