Iterative requirements are like those in other frameworks, except that they are developed iteratively and thus do not need to be complete in order to begin development. User Centered Design (UCD) complements the iterative approach, helping to identify true requirements.
Interviews are conversations with stakeholders to learn about their needs and to determine what a business process should look like once the project is completed.
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.
In Direct Observation, the team member(s) watch stakeholders perform their jobs in their workplace to learn how software will be used in its everyday context.
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.
A workflow diagram uses flow diagramming to illustrate the flow between processing steps.
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:
Thin slicing is a practice of breaking down a business process into use cases of decreasing value and tackling the use cases in order of priority.
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.
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:
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.
A persona is a fully-fleshed example of the kind of person who would use your system. It is more than just a role that a person would play at a given time, but rather is a fully-described person with a personality, motivations, etc.
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.”
“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.”
A persona map helps the team to prioritize personas and focus design on particular subsets rather than on all personas at once.
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 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.
The user goal diagram provides a view of all the persona map actors' goals relative to the project, allowing comparison, prioritization and other overview analysis.
The user goal diagram is a tool for analyzing the various goals that are relevant to a project.
Complete a user goal diagram:
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.
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.
A data model lists the data attributes and the logical structure of the data for a system, providing the basis for designing the system's physical data structures (tables and rows).
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.
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.