requirements development reference guide

5.0Reference Guide

Requirements Development

V. 1

Table of Contentspp Introduction to Requirements Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

pp Chapter One: 5.1 Analyze Stakeholder Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Scenarios Review Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Stakeholder Need Patterns Review Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

pp Chapter Two: 5.2 Prepare Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Visualization and Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Task Completion Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

pp Chapter Three: 5.3 Document Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Symptoms and Solutions for Commonly Found Problems in Reqs. Dev. . . . . . . . . . . . . . . . . . . . 50

Checklist for Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Related Content in RequirementCoach™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Requirements Excellence Framework™

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved


Table of Contents Cont’dpp Chapter Four: 5.4 Document Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Areas to Consider for Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Comprehension Exercise: Is it Functional or Non-functional? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Related Content in RequirementCoach™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

pp Chapter Five: 5.5 Create Requirement Visualizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Core Concept: Requirements Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Types of Visualizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Process in Enfocus Requirements Suite™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Task Completion Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

pp Chapter Six: 5.6 Elaborate with Additional Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Functional Requirement Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Non-functional Requirement Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Visualiztion and Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Task Completion Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112




Table of Contents Cont’dpp Chapter Seven: 5.7 Organize and Classify Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


pp Chapter Eight: 5.8 Prioritize Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125


pp Chapter Nine: 5.9 Verify Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137






© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved 1

IntroductionThe ideal process for developing functional requirements is to first create the high level requirement statements. Then, once all statements have been validated, the BA fleshs out the rest of the necessary detail in the requirement, such as the visualizations (refer to Task 5.5 Create Requirement Visualizations), requirement attributes, and unique fields for each requirement pattern (for information on attributes and how to use requirement patterns, refer to Task 5.6 Elaborate with Additional Details). This is known as Just-in-Time development, a practice which has become key in ensuring the delivered solution is built based on the most current organizational needs and requirements.

Two Most Common Requirement Errors

Two of the most commonly discovered problems in solution requirements development can be solved with Just-in-Time development:

1. Incorrect Facts

2. Omitted Requirements

While these problems are often difficult to completely eliminate, there are still ways you can reduce the risk of their occurrence. Keep this advice in mind as you perform the tasks in Task Group 5.0 Requirements Development and Task Group 6.0 Requirements Management.

Ways to Ensure Requirements Do Not Include Incorrect Facts

p� Map requirements to Stakeholder Needs/Scenarios to ensure all requirements are traceable.

p� Provide stakeholder reviews of requirement work products. Ensure representative stakeholders take part in the validation process.

p� Require that an authoritative source be specified for each requirement.

p� Verify each requirement with appropriate tests.

Ways to Ensure No Requirements Are Omitted

p� Develop requirements using functional decomposition. For information on this concept, refer to 3.0 Solution Conceptualization Reference Guide.

p� Elicit requirements from a wide variety of stakeholders. Ensure all stakeholder groups are represented.

p� Review requirements collaboratively. Features should be reviewed one-by-one with their Business Owners to ensure all requirements are accounted for.


Analyze Stakeholder Needs

5.1 Chapter One



IntroductionBusiness analysts need to work in a more evolutionary and collaborative manner with stakeholders to develop a set of requirements that reflect the stakeholder’s actual needs. It is the role of the BA to analyze the stakeholder needs that were gathered during elicitation and convert these into requirement specifications that can be used for design and development. The goal of analyzing stakeholder needs is to create a list of functional and non-functional requirements to build the solution by polishing the “raw” requirements provided by stakeholders. Others refer to this task as requirements analysis. In reviewing the stakeholder needs, the business analyst will be able to:

p� Gain a better understanding of the business problem.

p� Assess how complicated the solution might be.

p� Gain insights into how many stakeholder groups will eventually be impacted and involved.

p� Assess how many stakeholder groups share a common need.

p� Determine the specifics of use and distribution.

With the complete set of stakeholder needs documented in RequirementPro™ as a result of the tasks performed in Task Group 4.0 Stakeholder Needs Elicitation, the BA must now determine the best process for turning those needs into functional and non-functional requirements that can be used to build a solution that meets the goals of the organization. At Enfocus Solutions, we follow our own needs review process, which slightly varies depending on whether the stakeholder needs have been documented using Scenarios or Stakeholder Needs Patterns. Remember that all project teams have access to the Scenarios feature in Enfocus Requirements Suite™, but only teams with the Portfolio Performance Subscription have the ability to use Stakeholder Need Patterns.

Chapter One: Analyze Stakeholder Needs



Scenarios Review Process To review a collection of Scenarios in RequirementPro™, follow these steps:

1. Review results from Task 3.2 Conduct Stakeholder Analysis. The BA must be able to do two things:

p� Understand who the users are and what their activities are. (If this information wasn’t captured in stakeholder analysis for some reason, do it NOW).

p� Ensure all identified stakeholders are represented. If, for some reason, certain stakeholders didn’t participate in elicitation events, reach out in any way possible and make sure you have their input.

2. Analyze the needs according to each stakeholder perspective documented in your stakeholder analysis. With a basic Project Team Performance Subscription, even though you do not have the ability to use Stakeholder Personas in Enfocus Requirements Suite™, you still need to document stakeholder profiles of some kind as a result of Task 3.2. Then, ensure the set of needs that pertains to each specific stakeholder completely addresses the needs of each stakeholder group and doesn’t miss any vital elements. Ask the following questions, either in a conversation or to yourself as you review the needs:

p� Is the stakeholder group completely represented?

p� Are their needs complete? Review them with a representative stakeholder: ask, is this really everything?

p� Are the records worded poorly? If so, coach the stakeholders on how to write needs well.

3. Review each Scenario individually. Is the detail sufficient? Does there need to be a lower level of detail? Review each Scenario from a quality perspective:

p� Complete: Includes all required As-Is and To-Be information and steps, as well as any necessary attachments.

p� Clear: Must be clear to the BA where decisions are made, and what they are. This will be important information in the requirements development stage.

p� Functional: Must be useful and able to serve as a basis for creating either a use case or requirement. Does the scenario have enough information to create the type of record required by the project?




4. Assign an Action Item to the Record Owner to correct the record if it has insufficient detail or is poorly written. Either directly ask the stakeholder a question using the Action Item, or assign him/her the task of revising the submitted Scenario.

5. Map Scenarios to individual requirements as they are developed in Task 5.3 Document Functional Requirements. Every Scenario MUST map to a Functional or Non-functional Requirement to ensure all of the organization’s needs are met. Mapping Scenarios to requirements is a task easily performed with RequirementPro™. First, the BA develops and documents requirements. Then, s/he goes back to a Scenario record to manage the Related Requirements, linking specific requirements to the Scenario. A Scenario will most likely have multiple Related Requirements, as seen in the screenshot below.




Scenario Review Checklist

Refer to this checklist to make sure your Scenarios are in good shape as you complete the process of stakeholder needs elicitation and move into the requirements development stage.

✓

Complete:

p� Includes adequate As-Is and To-Be information.

p� Includes As-Is and To-Be steps.

p� Includes necessary attachments.

Representative of the stakeholder’s perspective.

Clearly provides descriptions of decisions and how they are made.

Clearly provides a description of a situation, and not a solution.

Any questions by the BA have been clarified with the Record Owner.

p� Insufficient detail corrected.

p� Poor word choice corrected.

Clearly maps to at least one solution requirement.

Stakeholder Needs Patterns Review Process

1. This process starts out the same as the Scenario Review Process, but will quickly change in the next step. First, review the results from Task 3.2 Conduct Stakeholder Analysis. Before working with the needs, the BA must be able to do two things:

p� Understand who the users are and what their activities are. (If this information wasn’t captured in stakeholder analysis for some reason, do it NOW).

p� Ensure all identified stakeholders are represented. If, for some reason, certain stakeholders didn’t participate in elicitation events, reach out in any way possible and make sure you have their input.




2. Analyze needs according to stakeholder perspectives (similarly to step two in the Scenario Review Process). However, with the Portfolio Performance Subscription, this step is easier to perform, because you have the advantage of analyzing needs according to the perspectives documented in the Impacted Stakeholder Personas.

Review the needs from the perspective of every impacted persona; this can be done by viewing the Impacted Stakeholder Persona records in RequirementPro™. Each record consists of a summary of the needs submitted by that particular persona. As you review the list of the persona’s Submitted Needs, keep in mind the following questions (also asked in the Scenario Review Process):

p� Is the stakeholder represented?

p� Are his/her needs complete? Review them with a representative stakeholder: ask, is this really everything?

p� Are the records worded poorly? If so, provide the stakeholders with coaching on how to write needs well.

3. Analyze needs according to pattern, across all perspectives. Look at all the reports that are needed, all process improvements, all workflow changes, etc. Tag needs as you review and analyze them. Remember that the project’s tags can be managed by an Admin user under the Project Settings Icon on the RequirementPro™ Menu bar. In addition to other topics that suit your project, ensure each need is tagged according to...




Whether It Is in Scope or Out of Scope

You may not want to delete an out of scope need completely, because it may contain valuable information that can be used in a different project. However, if the need is indeed labeled as Out of Scope, there’s no point in the project team addressing it. Keep in mind that there shouldn’t be many needs out of scope if you’re eliciting needs according to feature, as instructed in the elicitation process suggested in the Requirements Excellence Framework™.

Priority

The Record Owner uses the priority scale Very Low, Low, Medium, High, and Critical when s/he completes the Scenario. To differentiate, it is a good practice for the BA to use another prioritizing scale when it comes time for him/her to tag according to priority. An example of another scale you may want to use: Not Important, Slightly Important, Moderately Important, Very Important, and Essential.

Category

These categories will be similar to the Stakeholder Need Pattern names, but may differ based on the needs of your project. Make sure the categories are appropriate for the project, and customize if necessary. Tagging according to category will help to ensure all needs are accounted for in a particular group. Examples of categories include:

p� Transaction Processing

p� Reports


p� Workflow

p� Security



4. As requirements are developed in Tasks 5.3 and 5.4, map each need to either a Functional or Non-Functional Requirement. At this point, the requirement records will consist of a high level of detail. Simply matching up needs with their requirement counterparts will help do two things:

p� Organize duplicate needs. Various stakeholder personas will provide the team with their needs, and some of those personas are going to give you similar needs. Make sure all duplicate needs map to the same requirement.

p� Account for every requirement by linking it to a need. The need is in turn linked to a stakeholder persona, which is a description of a group of people with a particular stake in the success of the project. This chain ensures requirements are traceable, and that the team always knows where the requirements came from.

5. Review the entire population of needs to ensure everything is accounted for. Ask the Sponsor of each feature to determine whether the feature’s needs are complete. Also, make sure every need is either mapped to a requirement or tagged as Out of Scope. Quickly review the stakeholder needs index in the application to ensure all needs marked as In Scope have related requirements in RequirementPro™. This information can be viewed on the right side of the index, as displayed in the screenshot below.




Stakeholder Needs Patterns Review Checklist

Refer to this checklist to ensure your stakeholder needs are good sources for requirements.

✓

Complete:

p� Includes enough detail to develop requirement specification.

p� Includes necessary attachments.

Validated that it is representative of a true stakeholder need.

Validated that it describes the need itself, not how to provide it (i.e., the solution).

Any questions by the BA have been answered by relevant stakeholders.

CollaborationIn contrast to elicitation, the collaboration that goes on while performing this task is a lot more informal. Most of the process of analyzing stakeholder needs can be performed by the BA and his/her project team. However, as the BA reviews the needs entered in RequirementPro™, he/she often runs into clarity issues or a lack of information. In cases like this, it is the responsibility of the BA to reach out to relevant stakeholders and correct inconsistencies and misunderstandings.

As you review needs, when you come across something that is ambiguous, unclear, unmapped, lacking information, or lacking attachments, contact the individual stakeholders that are related to the poorly written need and ask them for some help in completing and understanding it. The easiest way to do this is by assigning the stakeholder an Action Item. In the Action Item, ask the user a specific, context-free question, or request that s/he performs a specific task. For example “Add more detail to the Scenario.”

Another good practice to rectify poorly written Scenarios and Stakeholder Needs Patterns is to host a meeting. Invite the members of a specific user class or stakeholder persona and review their needs in a group discussion. Also, a meeting like this helps let the stakeholders feel involved in the project, and in the overall success of the solution.


Prepare Use Cases

5.2 Chapter Two



Chapter Two: Prepare Use Cases

IntroductionTo understand the necessary functions of a system, it is common for the business analyst to focus on who (or what) will use it and then look at what the system must do for the users to help them achieve something useful. To do this, business analysts often employ use cases, a tool which helps to ensure the coordination of business processes by providing a common focus for varying activities that help to lead to specific requirements, architecture, standards, and policy discussions. Use cases can be used in conjunction with stakeholder needs and business rules to begin defining specific functional and non-functional system requirements. Use cases should be employed in tandem with other requirement elicitation techniques.

Rather than asking users what they want a system to do, use cases focus requirements development on what the users need to accomplish. The use case approach should include describing all tasks that users will need to be able to perform using the system. The use case is not intended to define all system features; it identifies and describes interactions between key systems and stakeholders and serves as a guide that leads to further development, clarification, and organization of requirements. It is necessary for stakeholders to ensure that use cases lie within the solution scope. When preparing use cases, there should be a focus on the goals that users have with a system, rather than emphasizing system functionality.



Core Concepts

Use Cases Are Prepared by Business Analysts

Stakeholders define scenarios, and then business analysts use those scenarios to develop use cases. A scenario is an encompassing description of a business problem that contextualizes an overall issue and focuses on interactions an actor has with a system. For clarification, a use case is a collection of related scenarios, and a scenario is only one instance of a use case. Use cases are to be created by business analysts only after the BAs have conducted scenario analysis in Task 5.1.

Use Cases Are to Model Desired Processes

Use cases should be used to model the desired process, not the current process. Using scenarios to create use cases can confuse some business analysts. Scenarios must be analyzed and not simply documented to be beneficial when developing use cases. Scenario analysis is necessary for reflecting the changes that stakeholder’s desire. Usually, use cases are made from the input of several different scenarios which aim to achieve a goal in the future process, and essentially model the use cases. Scenario’s need to be analyzed and input into the use cases as they contain the possible steps and behaviors required to achieve the goal of the use case.

Use Cases Remove Waste and Non-Value Added Steps

Use Cases should focus on the “to be” state of a process to ensure that waste and non-value adding steps are removed. The goal of use cases is to produce a set of functional requirements based off of user processes and experiences. However, the business analyst must keep in mind that scenarios include waste and non-value adding steps. Through workshops and the use of visualization methods, business analysts should be able to identify and remove waste and non-value steps present in scenarios before creating final use cases.

Use Cases Cannot Reflect All Requirements

Karl Wiegers, a leading speaker, author, and consultant in the requirements engineering and software process improvement arenas, cautions BAs to avoid a common use case trap. Wiegers acknowledges that uses cases can reveal most, but not all, functional requirements, so requirements shouldn’t be forced into use cases.

Two Categories of Use Cases Exist

There are two different categories of use cases. One category of use cases is referred to as business use cases. Business use cases reflect a relatively high level view of a process and are usually utilized by high-level executives and the like. The other category of use cases is referred to as system use cases which prescribe what is needed to build a system, or how actors can interact with the system to achieve their goal with a system. Business use cases and system use cases can be further defined as containing high, medium, or low levels of detail.




Use Cases Explain Processes and Hook Up Requirements

As an expert on use cases, Karl Wiegers explains that use cases shift the perspective of requirements development to discussing what users need to accomplish, in contrast to the traditional elicitation approach of asking users what they want the system to do. Any sequence of interactions between a system and an actor can be made into a use case, so all processes explained in a use case will describe what the users will need the system to do. Stakeholders can then affirm that each use case lies within the scope of the project. Wiegers states that, “In theory, the resulting set of use cases will encompass all the desired system functionality. In practice, you’re unlikely to reach complete closure, but use cases will bring you closer than any other elicitation technique I have used.“

ProcessLike requirements, the amount of detail necessary to prepare an effective use case depends on the project and organization. For example, if you’re going to purchase a solution, you should include as much detail as possible. If you’re working with your organization’s own experienced team of developers, you probably only need to provide them with the basic details.

As you move through the steps for developing use cases briefly listed below and discussed in the following sections, keep in mind how much detail is required and what use case level you will be handling, either a business use case or a system use case. Once you’ve determined the level of detail for your use cases, review the fields available on the use case and make a decision about which ones you consider most important, and which ones you can leave blank. Communication and collaboration with stakeholders is very valuable throughout use case development because stakeholders know a large part of the information necessary to create a use case. Scheduling stakeholder workshops throughout the preparation of your use case is highly recommended.

1. Gather Background.

2. Enter Details into RequirementPro™.

3. Define Primary and Secondary Actors.

4. Determine Preconditions and Postconditions.

5. Document Assumptions and Issues.

6. Document Basic Primary Path Details.

7. Develop the Primary Path.

8. Document Primary Path Exceptions.

9. Develop Alternate Paths.

10. Attach Visualizations.

11. Develop Requirements for Each Use Case.




1. Gather Background.

The first step to preparing use cases involves gathering background information and then inputting that information into RequirementPro™ and Enterprise Portfolio™. Enterprise Portfolio™ is helpful for documenting and analyzing information in conjunction with preparing use cases, but other documentation methods may be used. To gather all the necessary information required to prepare use cases, impacted components must be identified in Task 3.4 Assess IT Service Impact; stakeholder analysis must be conducted during Task 3.2 Conduct Stakeholder Analysis; supporting information must be gathered in Task Group 1.0 Business Analysis Planning and Monitoring and Task Group 2.0 Situation Analysis; related scenarios must be identified and then analyzed in Task 4.2 Gather Stakeholder Needs; and basic information must be input into RequirementPro™.

Identify Impacted Components and Secondary Actors.

According to Task 3.4 Assess IT Service Impact, it’s important to document all IT services affected by the project. This activity is important in identifying the total impact of the project and the secondary actors of use cases in the form of either a user or a system. While a primary actor is the actor that derives value from the use case and usually initiates the use case, secondary actors interact with the system in the use case but do not receive the goal benefit once the process described in the use case is completed.

Tip

It is essential to understand the differences between a user, a stakeholder, and primary and secondary actors at this stage:

A user is an individual who directly or indirectly interacts with the system, provides inputs to it, or receives output from it. Once you have identified all the impacted stakeholder personas in RequirementPro™, you will be able to easily identify the users of the system. It is important to note that users are always stakeholders, but stakeholders are not always users, because sometimes stakeholders do not interact with the system directly.

An actor is an entity outside the system that interacts with the system for the purpose of completing an event. Some users can play multiple roles as actors depending on the goal at hand. The system behaves as though it is interacting with a specific type of actor regardless of what user class that individual belongs to.

Within a use case, a primary actor is always a user. However, a secondary actor may be a user, hardware device, or another software system; this is important to remember when defining the primary and secondary actors.




Identify Impacted Stakeholders.

A stakeholder is any individual who is affected by the project or who can influence its outcome, whether internal or external to the organization. An entire list of stakeholders usually consists of a wide variety of roles, but a few possible examples include:

p� Customersp� Managersp� Analystsp� Developersp� Testersp� Writersp� Sales Associates

p� Support Specialists

Enfocus Solutions, Inc. analysts suggest that stakeholders and stakeholder personas are input into RequirementPro™ during Task 3.2 Conduct Stakeholder Analysis. A stakeholder persona is an individual or group of individuals with similar roles who hold a specific interest in the business. The information acquired during Task 3.2 Conduct Stakeholder Analysis, will often prove vital throughout the project duration.

After performing stakeholder analysis, your project team will have a complete set of stakeholders from which to later select and define the actors of the use cases. It is not individual stakeholders who become actors, but the personas. To clarify, an individual stakeholder persona can play several different ‘roles’ or be different actors, as they interact with the system, and stakeholder analysis helps to identify all the possible roles that will interact with or be impacted by the system. Also, once you have identified the key representatives of each stakeholder persona, those individuals will be able to provide assistance in defining the most essential use cases and other requirements, as well as participate in use case workshops.

The outcome of this step is the identification of impacted stakeholders. Once you have a list of impacted stakeholders, you can then talk to them and determine what their ‘goals’ are to determine the goals of a use case.

Gather Business Rules and Terminology.

According to Use Case 2.0, another important activity that must be performed before developing a use case is to provide all necessary supporting information. This activity translates to Task 4.4 Gather Business Rules and Task 4.5 Document Terminology.

Supporting information helps you to capture important terms used to describe the system and define governing standards or policies. It also helps you ensure your project team does not miss any vital requirements that are not explicitly stated in the use cases. By ensuring supporting information like business rules and terminology are gathered in the Enterprise Portfolio in RequirementPro™, project contributors will help avoid miscommunication with each other.




Review Related Scenarios and Conduct Scenario Analysis

A scenario is a description of a business problem from a stakeholder’s perspective, meant to be as total and complete as possible to contextualize an overall issue; scenarios focus on the interactions an actor has with a system to produce something valuable. Knowing this, it is easy to see why scenarios are beneficial to preparing use cases.

A major trait of a scenario is its ability to be used and grasped by people without specialized backgrounds. Scenarios are especially beneficial when used to convey an interaction from the point of view of an end user. This provides a common language that connects customer problems and technical solutions. Using scenarios also allows the more technical aspects of an issue to remain, appropriately, with the designers.

2. Enter Details Into RequirementPro™.




Once you have selected the goal on which the use case will focus, start filling in the basic details in RequirementPro™, like in the screenshot on the previous page, before developing the most important parts of the use case:

Name. Using an active verb followed by an object, the name of the use case should reflect the actor’s goal from the actor’s perspective. The following list includes a few related example use cases for buying a product online:

p� Search Catalog

p� Place Item in Shopping Cart

p� Pay for Items in Shopping Cart

Reference Number. It is possible the business analyst will discover many relevant use cases. Assigning a unique reference number to each use case ensures users they can quickly refer to a specific use case. This can also be useful for tracking test cases to use cases—test cases are derived from use cases, so the traceability can be valuable.

Priority. Stakeholders often claim all requirements are high priority. So, it is the business analyst’s job to use information from Use-Case Workshops and related meetings with stakeholders to determine the true priority of each use case. The following questions should be asked about a specific use case to determine its priority:

p� Is it a core business process?

p� Will it be used frequently by many users?

p� Is it requested by a favored user class?

p� Is it required for regulatory compliance?

p� Do other system functions depend on it?




To determine the priority, the analyst must balance the difficulty of implementation with the importance/value to the users, like in the graphic above. Ensuring use cases have relevant priority levels will help the analyst once it comes time to define requirements from the use cases. The analyst will be able to focus on high-value, low-difficulty use cases first.

Frequency. In this field, specify how often the use case is expected to occur. This field should note if the use case is frequently performed, seldom performed, or regularly performed though not often. This information will contribute to the decision to implement specific use cases before others. It also provides developers with information that may contribute to the design of the system. For example, if the use case is seldom performed, the developers may need to provide users with reminders of how to perform specific tasks.

Use case level. According to use case expert Alistair Cockburn in his book, Writing Effective Use Cases, there are five different levels of use case granularity. These levels provide a reference for how much detail needs to be included in the use case.

The level that the business analyst should focus on is the sea level, because it refers to use cases that fulfill user goals. A user goal is the goal that the primary actor has when using the system. There are goal levels both above and below the user goal, but the user goals are the important use cases to write. A sea level goal describes a single elementary business process, which is defined by UML expert Craig Larman as a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.




There are multiple ways to define a use case level. Some organizations label their use case levels in a 1, 2, 3 format, whereas some organizations define the level of detail within a use case as either high, medium, or low. What’s most important is that the organization has a defined method for labeling use case levels that is standardized. The analysts at Enfocus Solutions Inc. recommend labeling each use case in the Level field as either a business use case or a system use case, and then specifying the level by adding that the use case is either high, medium, or low detail. An example of a use case level could be “Business Use Case – Low.”

Description. Lastly, provide a brief description of the use case. Imagine you are describing the use case to a friend but can only do so in two or three sentences. The description doesn’t need to be detailed, but it should provide a brief overview of the use case and mention the primary actor. For example, if your use case is ‘Place Item in Shopping Cart, ’ the description could be ‘A customer has identified an item that they wish to purchase, so they have placed it into their shopping cart with the intent of paying for the item.’

3. Define Primary and Secondary Actors.

It is best practice to define the actors of a use case before filling in the other vital pieces of information. In RequirementPro™, the analyst enters this information into the primary path detail section.

The primary and secondary actors can be input from the list of impacted stakeholder personas previously created in step two, Task 3.2 Conduct Stakeholder Analysis. Ensuring you have created the list of impacted stakeholder personas provides you with the ability to quickly select the primary actor and, possibly, the secondary actors. Unlike primary actors, secondary actors may be users or systems. When selecting the secondary actor in RequirementPro™, you also have the option to choose from the list of impacted IT components created in step one.

The following list, developed by Karl Wiegers, includes some questions that the business analyst should ask to define the actors of a use case:

p� Who uses the system?

p� Who helps the system respond to an event?

p� Who provides information or services to the system?

p� Who is notified when something happens inside the system?




4. Determine Preconditions and Postconditions.

At this point in the process, the analyst is ready to enter the preconditions and postconditions of the entire use case. Later, you will enter any preconditions or postconditions that are specific to the primary path.

A precondition is a condition that must be true before a use case can be performed. This does not include the trigger, but refers to the state the system must be in when the use case is triggered, for example, “ATM contains money.” Generally, preconditions indicate that another use case has already been performed to set up the current use case. The analyst usually writes preconditions as simple assertions about the state of the world at the moment the use case begins.

A postcondition describes the state the system is in at the successful conclusion of the use case. Postconditions usually identify physical outcomes, such as “Mailing label has been printed,” or describe internal state changes, such as “Order has been stored.” Postconditions serve to define the preconditions for the next use case in the series.

Refer to the next page for an example of preconditions and postconditions that have been entered into RequirementPro™.

5. Document Assumptions and Issues.

An assumption refers to a fact about the system (or another system) assumed to be true for the use case to function appropriately. Assumptions are not evaluated or tested by the system. If assumptions are not met, then requirements of the system most likely need to change.

A good example of an assumption involves a spell check system that detects misspelled words and provides possible matches. One precondition states that there is some sort of dictionary set up to provide the matches. The business analyst assumes the user will be able to independently determine the correct spelling. If the assumption is wrong, the analyst must create requirements for defining the possible matches so that the user can make a selection.

Issues are problems or questions that have yet to be resolved. Sometimes, this field is referred to as Open Issues. Usually, this field will consist of a list of unanswered questions, for example:

p� What are the training requirements?

p� When is a cancelled request deleted from the system?

p� What change history must be maintained on requests?

p� What are the time periods for archiving requests?

p� How often does the system auto save?




6. Document Basic Primary Path Details.

The primary path, sometimes referred to as primary flow or normal flow, consists of the most common sequence of steps that the actors and system go through to accomplish the goal of the use case. In RequirementPro™, the Primary Path Detail section consists of actor information, primary path preconditions, primary path postconditions, and a description of the primary path.

The primary and secondary actors should have already been documented, so the analyst only needs to fill in the fields pertaining to primary path preconditions, postconditions, and a brief description. As previously stated, the primary path may have different preconditions and postconditions than the entire use case. The analyst should document primary path preconditions if there are alternate paths that also begin at the same step but contain different preconditions.

In addition to having different preconditions and postconditions, the primary path may require a separate description from the one that refers to the entire record. In this case, the analyst should provide another description that differs from the one displayed at the top of the record.

Documenting the primary path in RequirementPro™ involves simply pressing the Primary Path tab and entering your collected data in the appropriate fields.




7. Develop the Primary Path Steps.

The next major part of a use case is the description of the major steps that are performed to execute the response to the event, the inputs used for the steps, and the outputs produced by the steps. The primary path, also known as a primary flow, consists of the most common, or default, sequence of steps that the actors and system go through to accomplish the goal of the use case. In the primary path, each step moves the actor toward the goal. When the steps are followed normally, everything flows smoothly in the system.

As you document the steps, you must be able to clearly understand the interactions that occur between the user and the system, like in the example on the previous page. The steps should be listed in the order in which they are performed and describe what an outsider would observe while watching the user and system interact. Remember the following tips when writing the primary path steps of a use case:

p� Describe both the actor and system behavior. Although the use case should be written from the perspective of the actor, the analyst should not forget to include the actions performed by the system.

p� Use active voice, present tense. Ensure that the actor is doing something—nothing is or has been done to the actor.

p� Specify an actor within each step. Each step should clearly define who is performing the action and, if anybody, who receives the action.

p� Try to limit the number of primary path steps to 10. Huge use cases with many steps are difficult to work with and analyze for requirements.

8. Document Primary Path Exceptions.

Sometimes, the primary path begins to follow an unintended flow of events that results in different postconditions than those of the primary path. These unintended flows are known as exceptions. Primary path exceptions are conditions that prevent a use case from completing properly. Exceptions do not result in the successful completion of the use case goal, and they often have both different preconditions and postconditions. There are many possible types of exceptions. Examples include business flow exceptions like mechanical failures, as well as technical failures like broken telecom links or power loss. Later, when developing functional requirements, the business analyst will determine how the system could detect each exception and what it should do in each case.

In RequirementPro™, primary path exceptions are listed after the primary path, as displayed in the previous screenshot. To document an exception in RequirementPro™, the analyst should write the steps in the same manner as the primary path steps. When writing the steps, the analyst needs to specify the step at which the exception takes place and also make sure to describe how the exception is handled.




9. Develop Alternate Paths/Alternate Flows.

In other situations, the primary path branches off and the use case begins to follow another path but still fulfills the postconditions of the use case. An alternate path is another path besides the primary path by which the use case postconditions are satisfied and the actor can reach the same use case goal. Alternate paths represent less common flows or options available to the actor. Like exceptions, alternate paths most likely have their own preconditions and postconditions. Unlike exceptions, an alternate path may have different primary or secondary actors than the primary path, and it can include exceptions with their own steps, as well.

In RequirementPro™, an alternate path requires a separate record. The alternate path records hang off of the related use case record. An example alternate path is displayed below. First, enter the preliminary information like the preconditions and postconditions, and then, once the record is created, the analyst has the ability to develop the unique steps. The analyst should develop the steps of the alternate path in the same manner as the primary path steps. When writing the steps, remember to include the step at which the alternate path branches off of the primary path, as well as where it returns.




10. Attach Necessary Visualizations.

Now, the analyst should have a nearly complete use case consisting of all the information necessary to begin defining requirements. There is just one element missing—visualizations. The analyst needs to augment the use case text description with graphical models.

There are many products available to the business analyst developed specifically for this situation. We suggest selecting the best visualization aid, and then attaching completed diagrams and other visualizations to the use case record. The easiest way to illustrate a use case or set of use cases is to create a UML use case diagram, a process which we describe on page 27. Other possible visualization techniques that the analyst may find useful include:

Use Case Diagram—represent a user’s interaction with a system and portray the specifications of a use case, or actions that system users can perform while using the system. It is recommended that a use case diagram is developed in conjunction with the textual use case. Summarizing the interactions between the actor and the system, and providing a graphical, simplistic, high-level overview of the use case for the stakeholders (a picture is usually more understandable as a communication tool when dealing with the business) is what makes use case diagrams valuable.

UML Sequence Diagram—an interaction diagram detailing how operations are carried out according to time.

Flowchart—a diagram illustrating the flow of information.

UML Activity Diagram—a flowchart representing the flow from one activity to another. Flows may or may not be sequential.

UML State Machine Diagram—describes different states of a component in a system.

For more information on related visualization methods, refer to the Visualization Methods series on www.RequirementCoach.com.




11. Define Requirements for Each Use Case.

Once all information and visualizations have been entered, the analyst begins to actually use the finalized use cases to create functional requirement specifications in Task 5.3. At this stage in the process, Enfocus Solutions recommends breaking the use case up into more manageable slices, called requirements. According to Karl Wiegers, sometimes it is difficult for developers to understand use cases since they are written from the perspective of a user and not the system. Wiegers advises business analysts to develop functional requirements that developers can easily interpret. Technical detail, especially the level of detail developers may require, is often left out of use cases because they are written from the point of view of a user. Keep in mind that multiple other views are necessary for a developer to design a system.

A functional requirement is a requirement that contributes to the physical design of the system. Whereas a use case describes a goal the user has, a functional requirement states how the system should behave under certain conditions. Each section of the use case can be used to develop requirements. For instruction on how to write requirements, see our guides, Writing Strong Requirements and Developing Requirements Using Patterns, or refer to Task 3.6 Define Solution Features. Requirements expert Karl Wiegers has developed the list of questions below, which may be useful to ask when examining use cases for requirements. Refer to the following table to get an idea of which elements in your use cases will provide the best requirements.

SECTION QUESTIONS TO ASK

Preconditions p� What functionality is needed to test the precondition?

p� What happens if a precondition isn’t satisfied?

Primary Path and Alternative Paths

p� What functionality will let the steps take place?

p� Where are branches needed into alternate flows?

p� What functionality is needed for each alternate flow?

Exceptions p� What functionality will detect and handle every exception?

p� What system recovery or reset operations might be needed?

Postconditions p� How does the system satisfy visible and invisible postconditions?

Business Rules p� What functionality will enforce each business rule?




In RequirementPro™ requirements are usually created under the Requirements Development tab. However, another method of documenting requirements is to create them within the use case record they are based on so that the requirement is always linked to the use case. Ensure requirements are related to their associated use cases within RequirementPro™. Mapping requirements to the use case it was derived from establishes a high level of traceability which can be used by development to gather more context around the requirements they develop, as well as for the development of test cases, and debugging of defects in the future. Referred to as requirement bundling in Enfocus Requirements Suite™, we will describe this process in Task 6.1 Create Requirement Bundles.

Once business analysts have developed functional requirements based on the use case, they should focus on creating the non-functional requirements that will help to complete the system design. Non-functional requirements describe the operation or performance of the system, and, therefore, cannot be derived from a use case. Non-functional requirements are the type of requirement that captures conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have. Non-functional requirements cover things like security, performance, usability, compliance, documentation.

CollaborationCollaboration and communication is essential when trying to create solid use cases. One of the first things to do when preparing use case notes is to consult relevant stakeholders; it is impossible to develop a good set of use cases without them. To successfully develop a set of appropriate use cases, the business analyst must communicate and collaborate with related stakeholders in a similar way explained in 4.0 Stakeholder Needs Elicitation Reference Guide. Be sure to host meetings with stakeholders and hold use-case workshops to investigate the sequence of actions performed by each actor as well as the system responses.

Another approach for collaboration is to hold use case review sessions including relevant stakeholders. Review sessions with stakeholders ensure that the use case will be effective and solidly reflects stakeholder needs. Using a stakeholder’s scenario for reviewing the use case is recommended because the scenarios they wrote are really just samples of how they might use the use case. Try and answer the question “Can the use case effectively handle this scenario?”

While collaborating with stakeholders, make sure you ask them the types of questions that will provide good information. Instead of asking, “What do you want the system to do?” ask more direct questions like, “Describe a goal you need to accomplish with the system.” As a stakeholder describes their goals, keep asking “Why?” so you can drill down to their real needs. Remember to ask open-ended questions and don’t forget to address the exceptions.




Some more questions which can be asked when working with stakeholders to define use cases (or to ask yourself) are listed below by category.

To understand the actors involved you could ask:

p� “Who (or what) will provide information to or receives information from the system?”

p� “Who or what will interact with the system”

p� “Which role has this goal that we are talking about today? Does any other role have the same goal?”

To understand what starts the paths (trigger) you could ask:

p� “What causes the actor to need this use case?”

To understand postconditions you could ask:

p� “If all goes well with this use case, what is the outcome?”

To understand what the primary path is you could ask:

p� “What would it look like for you if everything worked perfectly?”

To understand/get the steps:

p� “Imagine that you are the actor and I am the system, how would we interact to achieve <use case goal>? What are the steps? What do each of us do?”

p� “What specific steps need to happen in order to achieve <use case goal>?”

When/If need to order sequence of steps you could ask:

p� “In what order would the actor complete these steps?”

To understand exceptions you could ask:

p� “Is there anything that could go wrong at this step?”

To understand alternative paths:

p� “Are there any alternative ways to accomplish this step?”

In addition to asking the right questions, stakeholders, project contributors, and even users can gain clarity, and therefore increase their ability to communicate their thoughts and needs, through the use of visualization methods. There is always room for collaboration when reviewing use cases, and stakeholders and project team members alike can participate in creating and analyzing visualization methods to achieve the maximum amount of collaboration and clarity possible while defining use cases and functional requirements.




Visualization and ElaborationConstructing and implementing visualizations throughout the process of creating use cases is considered to be a best practice at Enfocus Solutions Inc. Use Cases visualization techniques like Use Case Diagrams, Sequence Diagrams, State Machine Diagrams, and Flow Charts help project contributors to contextualize the use case and later develop functional requirements. In addition, visualizations increase collaboration and communication for all involved. Different visualizations are also more valuable to some people than others—for example, the use case diagram is great for stakeholders because it gives that simplified graphical overview of the use case—it’s easier for them to understand. Sequence diagrams (and all the more technical visualizations) are probably going to be more helpful for developers, a technical team, or QA because they are more technical in nature.

Use Case DiagramUse Case Diagrams represent a user’s interaction with a system and portray the specifications of a use case, or actions that system users can perform while using the system. Use Case Diagrams are meant to outline general behavior, so they should focus on business goals rather than system goals. Because Use Case Diagrams are meant to display an easily understandable, high-level view of a system, they provide a simplified and graphical portrayal of what the system must do from the point of view of external users. Remember that use cases should be established from the viewpoint of the project stakeholders and not from the more technical viewpoint of developers.

Because Use Case Diagrams are so simplistic, they are a good means of graphic communication for stakeholders. The purpose of Use Case Diagrams is to provide a high level view of the system and relate the requirements in layman’s terms for stakeholders. Use Case diagrams are used for requirements analysis, high-level design, and are also used to model the context of a system.

Create a Use Case DiagramBelow are basic steps to take when creating a use case diagram:

1. An easy way to begin creating a Use Case Diagram is to identify as many actors as possible. According to the book, UML Xtra Light, actors are the source where the use cases come from and, thus, are a good starting point.

2. Next, look at how the actors interact with the system to identify an initial set of use cases.

3. Connect the actors with the use cases on the diagram that are involved with each other. If an actor supplies information, initiates the use case, or receives any information because of the use case, then there should be an association between them.

4. When considering a flow, it is important to remember that there are two main parts, the basic flow of events and alternative flows of events. The basic flow is the sequence of events that “normally” happens when a use case is performed. The alternative flows of events include optional or unique characters in relation to the normal behavior, and variations of the normal behavior. Alternative flows of events are simply detours from the basic flow of events. Some of the alternative flows of events will return to the basic flow of events and some will end the execution of the use case. An example of an alternative flow could be a credit card failing when a customer places an order.




Sequence Diagram

Sequence Diagrams display how processes are ordered and the interaction among all the affected objects. In a Sequence Diagram, shown on parallel lines are different processes, or objects, that live concurrently. Horizontal arrows are included to portray the messages exchanged between the processes in the order in which they occur. This allows for a graphical description of runtime scenarios.

The following diagram was taken from www.Creately.com, a useful web-based visualization tool.




State Machine Diagram

State Machine Diagrams, also know as State Charts or State Diagrams, illustrate distinct behavior modeled through finite state-transition systems. Simply put, State Machine Diagrams describe the different statuses, or states, of an object and the events and conditions that cause an object to pass from one state to another. Arrows are used to run from the start of a process towards the end to represent the order in which activities occur. The diagram will cover a single object over a period of time, and the object may span several system use cases.

Following are the main purposes of using State Machine Diagrams:

p� To model dynamic aspect of a system.

p� To model lifetime of a reactive system.

p� To describe different states of an object during its lifetime.

p� To define a state machine to model states of an object.

The below example of a State Machine Diagram that describes a booking system was taken from www.Creately.com.




Activity Diagrams

Activity diagrams show the complete sequence of activities for a single process. Activity Diagrams can be used to display business and operational workflows step by step for components in a system to portray the complete flow of control. Arrows are used to run from the start of a process towards the end to represent the order in which activities occur.

Activity diagrams can be used to indicate flows among steps that transfer physical matter (e.g., gasoline) or energy (e.g., torque, pressure).

Following are the main usages of activity diagrams:

p� Modeling work flow by using activities.

p� Modeling business requirements.

p� Gaining a high-level understanding of the system’s functionalities.

p� Investigating business requirements at a later stage.

The following Activity Diagram was taken from www.Creately.com.




Flowcharts

A flowchart is a diagram that displays the sequencing of activities in a process, the participants responsible for each activity, and the artifacts used during the process. According to Howard Podeswa in The Business Analyst’s Handbook, this technique is commonly used to analyze the impact of change on end-to-end business processes. It is also used to model user interactions in requirements. According to the book, Information Technology Project Management: Providing Measurable, Organizational Value, flowcharts can be useful for documenting a specific process in order to understand how products or services move through various functions or operations, and can also help to visualize a particular process and identify potential problems or bottlenecks while being analyzed. Flowcharts are useful because interpreting your flowchart will help you to:

p� Determine who is involved in the process;

p� Form theories about root causes;

p� Identify ways to streamline the process;

p� Determine how to implement changes to the process;

p� Locate cost-added-only steps;

p� Provide training on how the process works or should work.

Business analysts can use flowcharts for a variety of tasks. Flowcharts can be used to analyze the impact of change on business processes during process improvement or when developing requirements for an IT system. Flowcharts can also be used to model the user-IT interaction in the user requirements.

The diagram below was taken from www.Creately.com.




Task Completion ChecklistRequirements expert Karl Wiegers developed the following checklist. Refer to this list when developing use cases to ensure you have all-important information documented.

ARE YOUR ATTRIBUTES VARIED AND INCLUDE: ✓

Is the use case a standalone, discrete task?

Is the goal or measurable value of the use case clear?

Is it clear which actor(s) benefit from the use case?

Is every actor and step in the use case pertinent to performing that task?

Do the preconditions and postconditions properly frame the use case?

Is the use case written at the essential level, free of unnecessary design and

implementation details?

Is the normal flow free of “if” statements for branches and errors?

Is the normal flow limited to approximately 10 steps?

Are all anticipated alternative flows documented, feasible, and verifiable?

Are all known exceptions, conditions, and how the system will handle them documented?

Are the steps for each flow clearly written, correct, unambiguous, consistent, complete, verifiable, and feasible?

Is it clear which entity performs each step in all flows?

Are there any common action sequences that could be split into separate use cases?

Are there any issues or assumptions that need to be recorded?


Document Functional Requirements

5.3 Chapter Three



IntroductionDeveloping full functional requirement specifications that include all details, visualizations, and relevant attachments can be an unwieldy task. At Enfocus Solutions, we prefer to break up the process into tasks performed at different times in the project lifecycle. At this stage, the business analyst is ready to develop the functional requirement statements and enter them into RequirementPro™ to be approved by their business owners. Later, in Task 5.5 Create Requirement Visualizations and Task 5.6 Elaborate with Additional Details, the project team will go back to the requirements and add their necessary details.

This chapter focuses on the development of functional requirements, and not non-functional requirements, which will be covered in the next chapter. While the processes for documenting these two requirement types are similar, there are some differences in the ways the BA will go about defining and documenting them. We’ll discuss these differences in the next chapter.

Core Concepts

What is a Requirement?

Before discussing the different types of requirements and the writing process for solution requirements, let’s determine exactly what a requirement is. This may seem like a simple concept to many, but the word “requirement” can often be interpreted in a number of different ways depending on the individual. An executive may believe a requirement to be a high-level product concept or business vision; however, a developer probably believes requirements are supposed to look like detailed user interface designs. And to really mix things up, a customer most likely believes requirements are just solution ideas. None of these definitions are correct; the meaning of the term varies according to the individual’s perspective.

We need to agree upon a clear definition of the term “requirement” before we are able to further explore the process of requirement development. The Guide to the Business Analysis Body of Knowledge (BABOK) by the International Institute of Business Analysis (IIBA), a respected authority on business analysis, sufficiently defines a requirement as:

“a condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.”

Chapter Three: Document Functional Requirements



But, what exactly does that mean? Well, a requirement is a statement of a business need—a feature or function that a stakeholder wants. A requirement identifies a necessary attribute, capability, characteristic, or quality that adds value to a system from the perspective of a stakeholder. Requirements serve as a basis for the design and implementation stages. The purpose of requirement specifications is to provide direction to developers building the solution without telling the developers exactly how to go about it.

Business analysts tend to disagree on how much detail belongs in a requirement specification. When written correctly, requirements should provide developers with a clear idea of what needs to be done to implement the solution, but they should not provide too many technical details; determining that type of information is the job of the developer. Also, remember to ensure requirements are clear and concise so that progress can be measured and areas in need of attention can be identified. The amount of detail that should be included in a requirement specification will vary according to the type of requirement.

Poorly Written Requirements

The following list includes examples of poorly written requirements. Note how the statements are unclear and either lack the necessary detail or include too much of it. Also note how they are inconsistent in their structure.

p� Provides the ability to provide easy downloads of reports into excel or other spreadsheet packages. p� Supports automatic periodic billings to selected Customer/Providers (e.g., billing for

license renewals at specified time annually). These recurring invoices can be set up for user-selected time periods and starting and ending dates.p� Bills by type of Customer/Provider.p� Calculates interest-free periods.

p� The system shall process all mouse clicks quickly to ensure user’s do not have to wait.

Well-Written Requirements

Below is a list of examples of well-written requirements created for a project. Note that one requirement has attributes (a concept which will be discussed in Chapter Six: Task 5.6 Elaborate with Additional Details) in addition to the requirement statement. Also note how the statements vary in detail while never getting too technical.

p� System shall permit Accounts to be shared across multiple years (i.e., project accounts). p� System shall provide a generic cost accumulator code.p� System shall simultaneously support bases of accounting for the appropriate fund types.

pp Cash basis pp Modified accrual basis pp Accrual basis

p� System shall provide for Chart of Account segments to have a long description of at least 50 alphanumeric characters.p� System shall provide multiple levels of spending plan control (none, absolute, warning)

within one agency.




Five Types of Requirements

BABOK has defined five types of requirements, which we also like to adhere to at Enfocus Solutions:

p� Business Requirements

p� User Requirements

p� Functional Requirements (Solution)

p� Non-functional Requirements (Solution)

p� Transition Requirements

Some of the most noticeable differences between these types of requirements are things like the amount of detail that they include and the required structure of their deliverables. When considering the types of requirements, there are three levels of detail and structure. Business requirements are the highest level and the broadest in terms of detail. Then, there are user requirements, which are loosely structured and discuss the needs of the system in terms easily understood by all stakeholders involved. Lastly, solution and transition requirements consist of the lowest level of detail, describing exactly what is needed to convey the appropriate message to the design team. Solution and transition requirements should follow a strict format. In RequirementPro™, requirements are treated differently according to their amount of detail.

How do you differentiate between business requirements and solution requirements? According to Robin Goldsmith in Discovering REAL Business Requirements for Software Success, the main difference between business and system, or solution, requirements is not a matter of detail, but rather a matter of what versus how. The solution requirements are able to satisfy the business requirements. Like Goldsmith says, systems are there to support the business, not the other way around.

Business Requirements

Business requirements are high-level requirements that specify the objectives that the business expects to achieve in a project and provide the “why” behind the decision to implement the chosen solution. In Enfocus Requirements Suite™, business requirements include the Problem Statement, Vision Statement, Capability Gaps, Business Need, Business Objectives, and Constraints, and Features. This type of requirement does not usually follow a rigid structure, although a standardized format should be set for each type of record so that all records within the enterprise are consistent. For more information on these requirements, refer to the 2.0 Situation Analysis Reference Guide.




User Requirements

User requirements are requirements that specify what the user needs in terms of the system. This type of requirement describes user goals and tasks that users must be able to perform with the system. The content of a user requirement is not as detailed as the lowest level of requirements (which consist of solution and transition requirements). This is because user requirements should be written by stakeholders using a common terminology that is easily understood by any reader—no technical jargon is found in user requirements. In Enfocus Requirements Suite™, user requirements are translated to stakeholder needs, scenarios, and use cases. One possible method for entering stakeholder needs into StakeholderPortal™ or RequirementPro™ is to use need patterns that are similar to requirement patterns. For more information on how these requirements work in Enfocus Requirements Suite™, refer to 4.0 Stakeholder Needs Elicitation Reference Guide.

User requirements are a vital input to the gathering and documentation of solution and transition requirements. During requirements development, business analysts analyze stakeholder needs, business rules, and use cases and transform them into fully-detailed requirements that are necessary for successful product development. Solution and transition requirements must have the ability to be traced to user requirements so that stakeholders can see how their needs will be addressed by the new solution. Well-written user requirements are essential because there must be a clear source of solution and transition requirements.

Solution Requirements

Solution requirements are the lowest level and most detailed requirements that are used to design and implement the system. Solution requirements are the ones that will facilitate the achievement of business goals. These requirements often have acceptance criteria or a lower level of detail that can be described by attaching requirement attributes. For more information on attributes, refer to Chapter Six: Task 5.6 Elaborate with Additional Details. Solution requirements follow a rigid standardized structure and are sometimes written with the use of Requirement Patterns. The requirement pattern method (only available with Portfolio Performance Subscriptions to Enfocus Requirements Suite™) provides guidance on how to write requirements by using templates to write particular types of requirements such as performance, archival and storage, report and query, etc.

Solution requirements are commonly broken down into two categories, functional and non-functional requirements:

Functional Requirements

These contribute to the physical design of the system. According to BABOK, functional requirements describe the behavior and information that the solution will manage. This type of requirement specifies functionality that the developers must build into the system to enable users to accomplish desired tasks, thereby satisfying business requirements or objectives. Functional requirement statements generally follow the model, “The system shall <perform this action>.” These requirements are often reused in multiple projects since there may be multiple solutions needed for the same system. A good example of a functional requirement is “System shall support workflow processes for recurring transactions.”




Non-Functional Requirements

These describe the operation or performance of the system, contributing to the system architecture. According to BABOK, non-functional requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have. A non-functional requirement states how the system must perform, but there is no way to physically build the requirement. Like their solution counterparts, non-functional requirements are also commonly reused. It is important to note that, while they can often be atomic, non-functional requirements can also commonly be found as attributes of other functional or non-functional requirements. Non-functional requirements can address many aspects of the system, but one good example is “The system shall allow the user to access his/her account 24 hours a day/7 days a week.”

Transition Requirements

Transition requirements do not address the solution, but rather the enterprise-wide transition to the solution. According to BABOK, transition requirements describe capabilities that the solution must have to facilitate a successful transition from the current state of the enterprise to a desired future state. However, these capabilities will not be needed once transition is complete. Contrast to functional and non-functional requirements, transition requirements are not commonly reused. Whereas solution requirements are defined during the initial requirement development stage, transition requirements are not defined until solution assessment when the necessary change to support the organization is apparent. These requirements are meant to improve the business processes surrounding the system. Common transition requirements include data conversions and organizational changes, as well as changes to training procedures and software infrastructure.




Why Use RequirementPro™ to Document Requirements

Many organizations still use word processors like Microsoft Word to develop requirements. This is simply the wrong tool for the job in today’s environment. It is like trying to prepare the ground for building a large skyscraper by using a shovel and a pick. Using a modern requirements management tool such as Enfocus Requirements Suite™ is essential in today’s environment. Here is a list of reasons why word processors are not the right tool for requirements development and management:

p� Requirements are more data intensive than document intensive.

p� Requirements need to be managed as backlog to support agile and complex projects.

pp Support development iterations.

pp Support different teams.

p� Requirements are more than just text. To be complete, they must consist of:

pp Related business rules

pp Visualizations (Process models, data flow diagrams, wireframes, etc.)

pp Related documents, videos, screenshots, etc.

p� Requirements need to be managed individually and collectively, which requires a tool that provides:

pp Prioritization capabilities

pp Bundling capabilities

pp Lifecycle management capabilities

p� Requirements review and validation is a continuous process and not a single event, as suggested with a Word document.

p� Each type of requirement needs different types of data. RequirementPro™ provides predefined Requirement Patterns.

p� Requirements need to be traced forward and backwards from the source where they were created to deployment of the solution.

p� Multiple people need to work on the requirements at one time. This is impossible or very difficult with a word processor. It is important to track who made changes and when changes were made.

p� It is often necessary to gather additional data to make a requirement complete; with RequirementPro™, this can be done by assigning Action Items. Trying to track all of these in Word can be a nightmare.




Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. Because of the rapidly changing business environment, requirements developed today are often out of date within 6 months. The requirements process needs to place increased emphasis on collaboration and less on rigor and rigidity. The ability to support change is necessary. Users need to be involved for project success and this involvement needs to be ongoing — it’s not just a simple matter of participating in a requirements workshop at the front-end of the project. Acquiring an automated requirements management tool, such as Enfocus Requirements Suite™, that supports collaboration between development, users, and business analysts is essential before requirements are developed.

Solution Requirement States

Managing the state of requirement artifact objects is very important for a requirements management solution. Functional requirements in RequirementPro™ go through eight different states that control the requirement behavior. At each state, the behavior of the requirement can be quite different.

p� Draft: The initial draft of the requirement has been developed by the BA. In this state, the requirement can only be viewed by the author and admin users.

p� Active: The requirement can be viewed by all project contributors and stakeholders, but it has not yet been approved by relevant stakeholders. The requirement may still undergo a lot of change until it reaches the next state.

p� Approved: The requirement has been reviewed and approved by the related Feature Business Owner. The requirements for that set of features are complete.

p� Designed: The detail of the requirement has been fleshed out, including all field entries, attributes, and visualizations.

p� Bundled: The requirement has been grouped with other requirements into a bundle. However, the bundle has not been approved and finalized.

p� Baselined: The contents of the requirement’s bundle have been verified and approved, and are ready to be built. No more changes should be made to the requirement after this point.

p� Delivered: The requirement has been built and delivered by developers.

p� Descoped: It has been determined that the requirement does not fit into the current project’s scope. However, the record may still contain valuable information that will be useful in other projects, so the record remains visible to their authors and admin users.




INVESTed Requirements

All Functional and Non-functional Requirements should adhere to the acronym, INVEST. Keep this acronym in mind as you develop requirement statements and iteratively add detail.

Independent: Can it be built independently? The requirement must be defined, analyzed, built, and managed separately from all other features.

Negotiable: Are the details of how the requirement is to be implemented negotiable? The requirement is not an explicit contract. Ensure tradeoffs can be made if necessary.

Valuable: Will it deliver business value and meet an organizational need? The requirement must be valuable to stakeholders.

Estimable: Can the project team determine a good approximation of effort? It should be possible to determine the relative size of each requirement to ensure costs can be estimated and work activities can be planned.

Sized Right: Is it appropriately sized to be feasibly built? All solution requirements should have the same level of detail. This element of the acronym relates more to the attributes and other details that will be fleshed out in Task 5.6 Elaborate with Additional Details.

Testable: Can you clearly identify a test to ensure the requirement has been delivered? The project team must be able to verify whether the feature was successfully delivered.

Process

Step One: Develop requirement statements based on the outputs from Task 5.1 Analyze Stakeholder Needs and 5.2 Prepare Use Cases.

Once a complete set of stakeholder needs has been elicited, the business analyst develops the requirement specifications using a rigid structure and adhering to strict rules. There must be at least one requirement statement documented in RequirementPro™ for each Scenario/Stakeholder Need and/or Use Case in the application.

Some organizations believe use cases are functional requirements; however, the analysts at Enfocus Solutions haven’t found much success with this approach. In reality, use cases and requirements have two different vocabularies and levels of detail. Like requirements expert Karl Wiegers, we have found use cases are much more successful when employed as a technique to reveal the necessary functionality. With this approach, you’re not forcing the functionality to fit into the developed use cases; you’re using the use cases to frame the discussion. Stakeholder needs and scenarios act in a similar way, revealing the solution requirements.

To develop good requirement statements that can be used to build the solution, the BA must focus on two areas: the rigid and consistent structure of the requirement statement, and the strategic word choice.




Structure

A rigid grammatical structure, while seemingly redundant at times, helps to ensure there is only one interpretation of a requirement. We suggest using an effective writing structure that includes a requirement object with a unique identifier, a text, and whatever attributes are necessary. However, at this stage in the writing process, you are only concerned with the statement. It is helpful to write requirement statements in a consistent and simple fashion using a similar structure to the model below:

The system shall [perform this function].

The enterprise may already have a standard for writing requirement statements. In that case, the business analyst should always follow the standard. However, if a standard does not already exist the business analyst must determine what the standard should be so that all requirements follow the same grammatical structure. Requirement structure should never vary within an organization. The requirements specification is not a document on which to creatively vary your language in an attempt to keep the reader’s interest. Although you may see the words “the system shall” thousands of times over again, the structure helps to ensure requirements are easily read and interpreted.

It is also important to ensure requirement statements are as brief and concise as possible while still conveying the appropriate message. The sentence structure of the statement should be short and simple. The business analyst usually saves the bulky details for the description and attributes.

Word Choice

Determining the structure of the requirements is only part of the development process. The business analyst also needs to ensure the words chosen to convey the requirement statement are the best choice. The best requirements statements are simple, direct, and have a limited vocabulary. Requirements specification vocabulary should be uncomplicated and clear to mitigate the risk of confusion. It is the responsibility of the business analyst to ensure all requirements are stated unambiguously. Remember the following practices when finalizing the content of a requirement statement:

Begin with an actor. The actor should simply be “the system,” not an actual individual.

Use the helping verb “shall.” This is an industry-wide accepted term in requirement statements. Often, enterprises use the term “should;” however, that term may be confusing to the developers. For example, developers may wonder if it is imperative the system provides that ability or function, or would it just be nice to have? The word “shall” is more direct.

Conjunctions are dangerous territory. Be cautious when using “or,” “and,” “with,” or “also.” Often, these words suggest that several requirements have been combined into one—a huge problem once it is time to implement the requirements.




Take out all generalizations. Words like “usually,” “generally,” “normally,” and “typically” are weak and vague.

Avoid uncertainties. Uncertain terms such as “may,” “might,” “should,” “could,” or “probably” suggest wishful thinking more so than an actual requirement.

Do not ask for the impossible. What does it mean for the system to be “100% reliable?” Or if the system “pleases all users?” If acceptance criteria cannot be defined, then it is not a requirement.

Do not use technical jargon. Although business analysts often do not have a background in technical writing, analysts can learn from technical writing style guidelines to employ user terminology rather than technical software or hardware jargon.

The bottom line—avoid vague and ambiguous terms. Examples include “user-friendly,” “flexible,” and “efficient.” Those terms are most likely not defined in the organization’s business rules, therefore they are confusing to the developers who must be able to read the requirements. The person who wrote the requirement may have a different definition of the term “efficient” than the person who builds the requirements. It is important for the business analyst to remember this while developing requirements for a project.

Words to Avoid

According to requirements expert Karl Wiegers, good requirements are absent of terms that are vague, fuzzy, subjective, weak, and do not clearly state the intent of the requirement. Review the list below of words to avoid, created by Wiegers:

p� Minimize, maximize, optimize

p� User-friendly, rapid, easy, simple, intuitive, efficient, flexible, robust

p� Seamless, transparent, graceful

p� Improved, state-of-the-art, superior

p� Sufficient, adequate, at least

p� Reasonable, where appropriate, to the extent possible, if necessary

p� Few, several, some, many

p� Etc., including, and/or

p� Optionally

p� Support




Step Two: Document requirement statements.

RequirementPro™ consists of two separate repositories for solution requirements. These requirements can be documented in two different ways, either individually or enmasse.

1. The first way to document a Functional Requirement in RequirementPro™ is via the Functional Requirements index. When creating a new requirement, enter its related Feature, brief Name, Priority Level, the Record Owner, and the requirement statement. When you first enter the requirement, it will be labeled as a general functional requirement. Later, users with a Portfolio Subscription have the ability to apply a pattern to the requirement so that it’s easier to elaborate with the correct details (refer to Chapter 6: 5.6 Elaborate with Additional Details for more information).




2. The other way of entering requirements into RequirementPro™ is to import them as a group using a spreadsheet. Requirements can be imported according to their related feature. First, download the Excel spreadsheet template to document the high-level information, filling in the brief Names, Descriptions (i.e., the requirement statements), and Priority Levels for all of the requirements related to a specific feature. Later, if you discover you have missed any requirements for that feature, you can always use the first method of documenting requirements to enter them individually. After completing the template, save and upload the file to the correct feature in RequirementPro™. The requirements will appear on the Feature’s list of Functional Requirements.

Tip

Interface Requirements

Interface requirements are complex functional requirements that describe the interface between two systems. Most BAs believe that interface requirements are non-functional, because they do not directly support user activities. However, at Enfocus Solutions, we treat Interface Requirements as Functional Requirements, because an interface is something that developers will have to build. For every interface, remember that there must be at least two requirement statements: one system must have the ability to send information, and the other must have the ability to receive it. If the interface is just one requirement, you can’t break it up between the different development teams. Ensure you have at least one requirement to hand off to each team.




Step Three: Obtain Approval of the Functional Requirements Set.

After developing a set of requirements that is believed to be complete, the BA must verify that the requirement statements adhere to a specific list of quality characteristics, as well as the INVEST acronym described on page 40 and referred to throughout this guide. Checking to make sure your requirements are complete and well written before adding the detail and visualizations will ensure you don’t waste time working with poorly written requirements that do not meet the needs of the organization. Requirements that adhere to the quality characteristics listed in the table below will provide many benefits:

p� Significantly lower costs through less rework

p� Higher project success rates

p� Deliver more value to the business through effective requirements prioritization

p� Faster time to market through earlier detection of defects

p� Better alignment between IT and the business

p� Higher user satisfaction

p� More efficient testing

p� Avoid costly workarounds resulting from missed requirements

Requirement Statement Quality Characteristic Checklist

TERM DESCRIPTION ✓

Accurate Does it correctly represent the business need? It is important to ensure every requirement correctly illustrates the functionality to be implemented. The source of the requirement (i.e. an actual user/stakeholder or a high-level system requirement) is the reference you should use to check its accuracy. It must be apparent that the requirement furthers the objective it supports, and must be necessary to meet that objective. A software requirement that conflicts with a corresponding system requirement is not accurate. Only user representatives can determine the correctness of the requirements (since the requirements should be based on their stakeholder needs), which is why it is essential to include stakeholders in their inspection.

Atomic Is it independent of any other requirement? Dependencies between requirements can make planning, prioritization, and estimation much more difficult. However, dependencies can often be reduced by either combining requirements into one (by using attributes) or by splitting the requirements differently. A requirement should consist of one complete idea that can stand alone. It must be indivisible and irreducible. Essentially, each requirement must be independent of all others. Atomic requirements provide the means to test exactly what the developer must implement.





Complete Does it contain or reference sufficient detail, examples, pictures, and other explanatory material? Does it cover all attributes? Every requirement should contain a complete description that covers all attributes and includes enough narrative and all necessary attachments for the developer to design and implement that bit of functionality. Each requirement must fully describe the functionality to be delivered. It must contain all the information necessary for the developer to design and implement that bit of functionality. Every requirement should contain or reference sufficient detail, examples, pictures, and other explanatory material to describe itself sufficiently and appropriately. Simply put, if the requirement is implemented as written, the market need is completely addressed.

Modifiable When changes are necessary, will they be made easily, completely, and consistently? The requirement needs to establish a sound foundation for development that accepts the inevitability of change. A requirement specification is modifiable if its structure and style are such that any necessary changes to the requirement can easily be made. You must be able to revise the requirement when necessary and to maintain a history of changes made to each requirement. This dictates that each requirement be uniquely labeled and expressed separately from other requirements so that you can refer to it unambiguously.

Practical Is it feasible to perform with existing constraints, such as time, money, and available resources? The requirement must prove to be realistically achievable and cost-effective. Systems and their environments have practical and technical limitations and capabilities. Make sure that the implementation of each requirement is possible and cost-justified under the current constraints. A good way to identify and avoid infeasible requirements is having a developer collaborate with the requirements analyst during the elicitation process. To avoid specifying unattainable requirements,have a developer work with marketing or the BA throughout the elicitation process. The developer can provide a reality check on what can and cannot be done technically and what can be done only at excessive cost. Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility.





Prioritized How important is this requirement to the future of the business? How essential is a requirement to a particular service release? Although each requirement should document something stakeholders really need or something that is required to conform to an existing requirement, external interface, or standard, in reality, some system capabilities are more essential than others. Customer expectations are usually high, and timelines are short, so the project team needs to ensure the product delivers the most valuable functionality as early as possible. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a contributor. Prioritization is a good way to deal with competing demands for limited resources. The most important task when prioritizing requirements is to determine their actual value, meaning how the functionality to be provided will benefit the stakeholders.

Traceable Do you know the source of the requirement as well as the impact it has on other requirements? When a requirement inevitably changes, the answer to this question is essential for assessing the impact of the change. Any project contributor or stakeholder should be able to check the source of each requirement by tracing them back to their origins (e.g., a use case, regulation, stakeholder, or system requirement). If the origin cannot be identified, it is most likely unnecessary. If a requirement is untraceable, once changes occur, there will be inconsistencies between the upstream and downstream workflow. RequirementPro™ provides user friendly and scalable tool support for requirements tracing.





Unambiguous Did you make sure to avoid uncertain terms, jargon, and wordiness so that the requirement is clear and easily understood? One of the most common and detrimental mistakes in projects is the misinterpretation of requirements. All readers of a requirement statement should arrive at a single, consistent interpretation of it, but natural language is highly prone to ambiguity. Besides the use of unambiguous language, ensure there is no jargon in the requirement that could be confusing. A requirement needs to be concise and understandable so that it clearly communicates a specific message to development—developers must be able to build what the stakeholders want. Write requirements in simple, straightforward language appropriate to the user domain. “Comprehensible” is a requirement quality goal related to “unambiguous”: readers must be able to understand what each requirement is saying. Define all specialized terms and terms that might confuse readers in a glossary.

Valuable Does the source of the requirement have the authority to specify requirements? Every requirement has to describe something that the customers truly need or express something required for compliance to an external requirement, interface, or standard. If the requirement does not provide quantifiable or qualitative value to any stakeholders, then it is unnecessary.

Each requirement should document a capability that the stakeholders really need or one that’s required for conformance to an external system requirement or a standard. Every requirement should originate from a source that has the authority to specify requirements. Trace each requirement back to specific voice-of-the- customer input, such as a use case, a business rule, or some other origin.





Verifiable Is there a clear verification method? Can it be tested using quantifiable measures and indicators of strength? Testers should be able to verify whether the requirement is implemented correctly. If a requirement is testable and verifiable, it is ready for inspection, demonstration, and testing to determine if it is properly implemented by the service. Ensure quantifiable measures or indicators of strength are provided as evidence for verifications of every requirement. Testing should involve members of the architecture and test teams when verifying the quality of requirements to ensure that the requirements are feasible and verifiable. See whether you can devise a few tests or use other verification approaches, such as inspection or demonstration, to determine whether the product properly implements each requirement. If a requirement isn’t verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable.

Moving Forward

After all requirement statements are reviewed and approved by relevant stakeholders, the BA is ready to complete the requirement records by attaching necessary visualizations and adding the appropriate amount of detail. It is a good practice to develop the detail once the requirements have been placed into logical groups and bundled. We suggest ensuring you move quickly enough into adding sufficient detail so that the requirements don’t get old and useless.

Since there is so much involved in developing visualizations and elaborating on requirements, we describe these activities in separate chapters. For more information on these topics, refer to Chapter 5: Task 5.5 Create Requirement Visualizations and Chapter 6: Task 5.6 Elaborate with Additional Details.




Symptoms and Solutions for Commonly Found Problems in Requirements Development

CONFUSION OVER “REQUIREMENTS”

Symptoms p� An executive’s perception of requirements may involve a high-level business strategy or goal.

p� A developer or engineer’s requirements might look like a detailed design or engineering specification.

p� Customer-provided requirements occasionally read more like solutions. Project stakeholders often do not classify their requirements as high-level or detailed. Project participants, therefore, will have different expectations as to the amount of detail in the requirements.

p� Although users provide requirements, developers may not be sure what they are supposed to build.

p� If discussions during the development of requirements focus exclusively on functionality, participants might not understand the various kinds of information that fall under the broad fabric of requirements. Consequently, important stakeholder expectations might go unstated and unfulfilled.

Solutions 1. Recognize that there are several types of requirements.

2. Educate project participants on key requirements concepts, terminology, and practices.

3. Clearly define the type of requirements being pursued by the team.

INADEQUATE CUSTOMER INVOLVEMENT

Symptoms p� Users often think developers already know what they need, or they believe all that technical stuff, such as business requirements, do not apply to them.

p� Users frequently indicate they are too busy to spend the time it takes to gather and refine the requirements.

p� Users draw on unprepared users or software developers to supply all of the input to requirements.

p� Developers make requirements decisions without adequate information and perspective.

Solution Identify the various types of users. Each user will differ in their frequency of using the product, the features they use, and their access privilege level.




AMBIGUOUS AND VAGUE REQUIREMENTS

Symptoms Ambiguity exists when:

p� A requirement statement has several different meanings and there is uncertainty as to which one is correct.

p� Multiple readers interpret a requirement in different ways. Each

p� reader concludes that his or her interpretation is correct, and the ambiguity remains undetected until later—when it is more expensive to resolve.

A symptom of vague requirements is when:

p� Developers have to ask the analyst or customers many questions.

p� Developers have to guess at what is really intended. The extent of this guessing game might not be recognized until the project is far along and implementation has diverged from what is really required. At this point, expensive rework may be needed to bring things back into alignment.

Solutions 1. Avoid using subjective and ambiguous words when requirements are being written. Terms like minimize, maximize, optimize, rapid, user-friendly, easy, simple, often, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, and flexible are particularly dangerous.

2. Avoid the use of terms such as “and/or” and “etc.” It is acceptable to include the term “TBD” (to be determined) to indicate current uncertainties, but make sure you resolve them prior to design and construction.

REQUIREMENTS THAT HAVE NOT BEEN PRIORITIZED

Symptoms p� Declaring all requirements to be equally critical deprives the project manager of a way to respond to new requirements and other considerations such as changes in staff, schedule, and quality goals.

p� Approximately 90 percent of your requirements are classified as high priority.

p� Stakeholders might interpret “high priority” differently, leading to mismatched expectations about what functionality will be included in the next release.

p� Development teams balk at prioritizing requirements because they believe the business and user area have a better understanding of business priorities.

p� Users are reluctant to prioritize because they fear the developers will automatically restrict the project to the highest priority items and the other items will never be implemented.

p� Uninformed people are left to make the prioritization decisions, unaware of the implications of those decisions.




REQUIREMENTS THAT HAVE NOT BEEN PRIORITIZED CONT.

Solutions 1. Rank all requirements according to the return benefit each provides to the business.

2. Factor in the dependencies between requirements. In some cases influences outside the underlying business, such as state, federal, and industry regulations, may affect a specific priority.

BUILDING FUNCTIONALITY NO ONE USES

Symptoms p� System features that user groups said they needed but are never used or used infrequently.

p� Glitzy user interface that must be present for the software to be useful.

p� “Gold plating” from the developers, which adds unnecessary functionality or features that “the users are just going to love.”

p� Proposed functionality that is not clearly related to known user tasks or achieving business goals.

Solutions 1. Trace each Detailed Business Requirement back to its origin, such as a specific High-Level Business Requirement, business rule, industry standard, or government regulation. Requirements matrices are useful techniques for completing this task.

2. Identify the user groups that will benefit from each feature.

3. If the origin of a requirement is unclear, question whether it is really needed.

ANALYSIS PARALYSIS

Symptoms p� The development of requirements seems to drag on forever.

p� There is a prevailing viewpoint between all parties that development cannot begin until all Requirements are documented and approved.

p� All requirements must be modeled “six ways from Sunday,” the entire system must be prototyped, and development will be held up until all requirement changes cease.

Solutions 1. Identify the key decision-makers early in the project; they can resolve issues and help the project move ahead with development.

2. Make sure the scope of the effort is not too broad to address a single project.

3. Look for sets of requirements that are clear and cohesive and then drive them to closure. Then work through the remaining requirements for subsequent deliveries.




SCOPE CREEP

Symptoms p� New requirements are continually added during development. This symptom usually occurs when the product scope was never clearly defined.

p� New requirements are proposed, rejected, and then resurface later—with ongoing debates about whether they belong in the system—the scope definition is probably inadequate.

Solutions 1. Review the requirements research process to make sure no requirements or user types were overlooked.

2. The use of effective requirements gathering methods early on helps control scope creep.

3. Establish a meaningful process for standardizing your requirements specifications.

INADEQUATE CHANGE PROCESS

Symptoms p� The project does not have a specific process for dealing with requirements changes, resulting in new functionality becoming evident only during system or beta testing.

p� It is unclear who makes decisions about proposed changes.

p� Change decisions are not communicated to all those affected, and the status of each change request is not known at all times.

Solutions 1. Define a practical change-control process for your project.

2. Setup a Change Control Board (CCB) to consider proposed changes at regular intervals and make binding decisions to accept or reject them.




INSUFFICIENT CHANGE IMPACT ANALYSIS

Symptoms p� Developers or project managers agree to make suggested changes without carefully analyzing the implications. The change may be more complex than anticipated, take longer than promised, be technically or economically impossible, or conflict with other requirements.

p� Developers keep finding more affected system components as they implement the change.

Solutions 1. Analyze the impact of each proposed change.

2. Understand the implications of accepting a change on affected systems, identify all associated tasks, and estimate the effort and schedule impact.

3. Provide estimates of the costs and benefits of each change proposal to the Change Control Board before they make commitments.

INADEQUATE VERSION CONTROL

Symptoms p� Approved changes are not incorporated periodically into the Requirements document; project participants are unclear as to what is in the Requirements baseline.

p� Using a date to distinguish a document’s different versions. Different versions may have been drafted on the same date.

Solutions 1. Incorporate approved changes into the Requirements document periodically and communicate the revised document to all stakeholders.

2. Adopt a versioning scheme for documents that clearly distinguishes drafts from baseline versions.

3. Store requirements documents in an automated version control tool. Restrict read-write access to a few authorized individuals, but make the current versions available in read-only format to all project stakeholders.

INADEQUATE ESTIMATES FOR GATHERING REQUIREMENTS

Symptoms p� The project has missed major milestones.

p� There have been cost overruns.

p� There have been incomplete or inadequate requirements developed.

Solutions 1. Carefully review all time allocations and budgetary planning.

2. Rework and review all requirements descriptions to improve all written specifications.




Checklist for Functional RequirementsFunctional requirements describe the behavior and information that a solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses. In order to provide guidance to business analysis professionals, this checklist has been provided.

Base Requirements

Short Names

It is best to organize your requirements by providing shorter names to facilitate indexing. As requirements are varied, it is impossible to write every one in exactly the same fashion, though there are some guidelines that should be followed. Are your shorter names:

p� Consistent?

p� Written as a subject (e.g., Aging Report, Order Entry, Customer Setup)?

Requirement Specifications

Providing complete descriptions of system behaviours and potential interactions is a necessity. Are your requirement specifications:

p� Short and simple sentences rather than long narratives?

p� Precise and specific in wording (are you avoiding vagueness and ambiguity)?

p� Using the vocabulary of your particular business domain?

p� Clear and understandable to the developers?

p� Avoiding unnecessary design constraints?

p� Discreetly testable?

p� Written at a fine level of granularity?

p� Free of combined requirements?

pp Avoid using “and” or “or.” They might be indicators that you have combined more than one requirement.

p� Consistent with their wording?

pp We recommend using “shall” in requirements. “Will” or “must” can be used, but your choice has to be consistent with the rest of your requirements.

p� Free of terms that might be subjective or ambiguous?




Quality Characteristics

These are the characteristics of quality requirements. Are your requirements:

p� Accurate? pp Do they accurately state a customer or external need?

p� Complete? pp Is there anything missing? Remember to avoid terms like “to be determined.”

p� Prioritized? pp Are the requirements ranked in regards to importance of project inclusion?

p� Feasible? pp Can the requirements be implemented within known constraints?

p� Necessary?

pp Does the requirement document a real customer need?

p� Consistent? pp Does the requirement avoid conflicts with other requirements?

p� Traceable? pp Is the requirement linked to system requirements, use cases, and needs?

p� Testable?

pp Is the requirement implemented correctly? Can this be determined by testing, inspection, analysis, or demonstration?

p� Clear? pp Does the requirement description have only one possible meaning?

Reference: “Writing High Quality Requirements” by Karl Wiegers for Enfocus Solutions




Pattern (Available with Portfolio Subscription)

Requirement patterns are templates and guides to writing a particular type of requirement, such as performance, backup and recovery, report, query, etc. Each pattern specifies what information should be gathered for that type of requirement, what elements to include, and what to worry about. When using the Portfolio Subscription to Enfocus Requirements Suite™, you can document if your requirement pattern is:

p� Analytical Report and Query

p� Archival and Storage

p� Documentation

p� General Functional

p� Interface

p� Organizational Report and Query

p� Security and Access Control

p� System Connectivity

p� System Data

p� Transaction

Reference: “What is a Requirement Pattern?”

Business Rules

Business rules are generally organized by function, service/product, or processes and grouped into rule books. There are a few ways to ensure you are successfully using business rules. Are your business rules:

p� Inter-related?

p� Clearly defined?

p� Easily mapped?

p� Able to be validated?

p� Consistent with established business rules?

Reference: Requirements Excellence Framework™




Prioritization

Prioritizing requirements is critical for every project and necessary for allocating scarce resources; not everything can be a top priority. Is your requirement’s priority:

p� High?pp Is this requirement of the utmost importance and urgency? Does it have to be included in the next release?

p� Medium?pp Is this requirement necessary but not urgent? Can it wait for a later release?

p� Low?pp Is the requirement nice to have, but only if you can fit it in?

Reference: “Prioritizing Requirements” by Karl Wiegers for Enfocus Solutions

Requirements Classifications (Tags)

Tags are used to provide quick classifications of requirement groups. Tags can range from prioritization to size; this is customizable for your convenience. However, it is still important that your tags are appropriate. Are your tags:

p� Assessments of Needs? (Essential, Nice to Have, Not needed)

p� Business Values? (Cost Reduction, Revenue Generation, Image and Reputation, Customer Satisfaction, Employee Satisfaction, Process Efficiency).

p� Priorities? (Urgent, Important, Can Wait)

p� Complexities? (Simple, Moderate, Complex)

p� Iterations? (Iteration 1, Iteration 2, Iteration 3)

p� Releases? (Release 1, Release 2, Release 3)

p� Efforts? (Small, Medium, Large)

p� Impacts? (People, Process, Technology)

p� Corporate Compliances? (Risk, Audit, Internal Control, Regulatory)

p� Stakeholder Needs? (DBA, Internal Auditor, Compliance Officer)

p� Work Groups? (Business Unit, Enterprise, Extended Enterprise)




Glossary/Terms

A glossary of relevant, industry-specific terms needs to be provided for requirements. Different stakeholders can have different vocabularies, and a glossary is a way of decreasing miscommunication.

Acceptance Criteria

Acceptance criteria define what constitutes acceptance for determining if a requirement is completed and working as expected. Acceptance criteria are used in agile development, but help plan driven development as well. They help add certainty as to what the team building and provide helpful information for building acceptance tests.

Traceability

Requirements traceability refers to the practice of systematically ensuring that each requirement is explicitly covered in subsequent project documents. Traceability provides a way to ensure—and prove—that all original requirements were implemented and ultimately tested. Are you able to trace your requirements by:

p� User Needs?

p� Scenarios?

p� Use Cases?

Reference: Requirements for Traceability (Analyst Brief)

Dependencies

Ideally, requirements are independent as specified in the INVEST model. However, it is sometimes impossible to avoid dependencies. These dependencies occur when a requirement is dependant on another requirement to be functional. Upstream and downstream dependencies can easily be captured in Enfocus Requirements Suite™.




Requirement Attributes

Requirement attributes are descriptive details associated with specific requirements. These attributes are used to decrease subjectivity through their assigned values. These values are also integral to organizing, prioritizing, and analyzing your requirements. If you limit your attributes to the following criteria, your attributes are guaranteed essentials. Are your requirement attributes:

p� Expected behaviors?p� Exceptions?p� Data elements?p� Allowed values for data elements?p� Edits and validations?p� Error messages?p� Search criteria?p� Design notes?

p� Implementation?

Visualizations

Requirements visualization has many different meanings. Some view it as supplementing textual requirements with graphical illustrations and others view it as a form of user interface (UI) prototyping that is used for gathering customer requirements. If you use the following visualization techniques, your finished project has a greater chance of resembling what your organization initially envisioned.

Are you using:

p� Wireframes?pp Used to depict the page layout or arrangement of the content on a computer screen or a website’s content.

p� Data Flow Diagrams?pp Graphical representations of the “flow” of data through an information system modeling its process aspects.

p� UML Models?pp Standardized general-purpose modeling language.

p� Flow Charts?pp Diagrams that represent a process showing the steps as boxes of various kinds and their order.

p� Business Process Models?pp Graphical representations of an enterprise’s processes.




p� Mind Maps?pp Diagrams that are used to represent words, ideas, tasks, or other items linked to and arranged around a central key word or idea.

p� Concept Diagrams?pp Graphical tools for organizing and representing knowledge.

p� Videos?pp Great to capture meetings or interviews so that they can be shared with other members

of the team.

p� Rapid Prototyping?pp Refers to the activity of creating prototypes of software applications.

p� White Boards?pp Any glossy, usually white surface for non-permanent markings.

p� Entity Relationship Diagrams?pp Show data entities, attributes, and the relationships between them.

p� Decision Trees?pp Tree-like graph or model to show decisions and their possible consequences.

Reference: Visualization Method: Intro to Requirements Visualizations

Attachments

Attachments are useful for providing materials that are necessary for reducing ambiguity in requirements. This can be a perfect place to provide marked-up copies of existing reports and screen layouts.




Related Content in RequirementCoach™Analyst Brief: Business Requirements vs. Functional Requirements: This analyst brief is meant to help business analysts who struggle with understanding the differences between business requirements and functional requirements.

Analyst Brief: Requirements for Enterprise Mashups: As many organizations are beginning to use ‘mashups’ to create enterprise applications, this analyst brief should provide insight on how mashups allow organizations to rapidly implement new functionality via the use of web technologies, content from multiple data sources, reusable user interface components, and loosely coupled services.

Guide: Elements of Requirement Style: Writing requirements is hard! There is no simple, formulaic approach to software specification. High-quality requirements begin with proper grammar, accurate spelling, well-constructed sentences, and a logical organization. This technical guide, adapted from Karl Wiegers’ book More About Software Requirements (Microsoft Press, 2006), presents numerous style guidelines to keep in mind when writing functional requirements.

Training Course: Writing High Quality Requirements by Karl Wiegers: This self-paced workshop helps anyone performing the requirements analyst role on a software or systems development project become more proficient at specifying high-quality requirements. It presents extensive advice on how to examine requirements critically for problems and how to write clear, unambiguous requirements of various types. Many practice sessions give students experience in finding requirements problems, distinguishing requirements from design, interpreting customer input, writing precise functional requirements, specifying quality attributes, defining data items and business rules, and choosing alternative ways to represent requirements besides natural language text.

Wiegers Training: Video 13. Use Cases and Functional Requirements: Requirements expert Karl Wiegers discusses how to develop functional requirements based off of use cases.


Document Non-Functional Requirements

5.4 Chapter Four



IntroductionBefore we discuss the process for developing non-functional requirements, let’s take a moment to reflect on the differences between functional and non-functional requirements. According to Karl Wiegers in Software Requirements, a non-functional requirement is a description of a property or characteristic that a software system must exhibit or a constraint that it must respect, other than an observable behavior. In other words, non-functional requirements are all the other characteristics besides the behavior/capabilities of the system. Non-functional requirements can include many things, such as:

p� Design Constraints

p� Implementation Constraints

p� Performance Requirements, such as:

pp Response Time

pp Throughput

pp Latency

pp Degraded Modes

p� Quality Attributes, such as:

pp Usability

pp Robustness

pp Installability

pp Integrity

pp Availability

Chapter Four: Document Non-Functional Requirements



The process for developing non-functional requirements is slightly different than when defining functional requirements. However, a lot of what we discussed in Chapter 3: 2.3 Document Functional Requirements pertains to non-functional requirements, as well. Refer to the last chapter for important information that is also relevant to this chapter, such as:

p� The Five Types of Requirements and Their Differences

p� Why Use RequirementPro™ to Document Requirements

p� Solution Requirement States

p� INVESTed Requirements

p� Requirement Statement Quality Characteristic Checklist

p� Symptoms and Solutions for Commonly Found Problems in Requirements Development

Best Practices The process for defining and entering non-functional requirements is similar to that of functional requirements; however, there are some slightly different best practices for non-functional requirements.

p� To ensure all non-functional requirements are accounted for, the BA usually talks to technical stakeholders rather than business stakeholders. The people who will know the non-functional requirements are usually individuals involved in business continuity, as well as IT service owners that are aware of existing Service Level Agreements. Also, good sources of non-functional requirements are often system architects and developers. In addition to providing input for non-functional requirements, these types of people need to be involved in reviewing the completed set of requirements.

p� Remember that non-functional requirements should be collected in their own features separate from any functional requirements. This is a good practice for two reasons. Non-functional requirements pertain to the system as a whole, whereas functional requirements pertain strictly to user activities. Also, non-functional requirements are usually elicited at a different time than functional requirements.

p� There are a few specific documents that BAs have found useful in discovering non-functional requirements:

pp Enterprise Architecture documents

pp Service Level Agreements (SLAs)

pp Contracts

p� If non-functional requirements appear to be missing, or it is difficult to discover them, consider asking users what would constitute unacceptable performance, usability, integrity, reliability, etc. By defining unacceptable characteristics, you can determine what the system needs to be able to do.




Non-Functional Requirement States

Non-functional requirements go through slightly different state changes than functional requirements, because they can be reused in multiple bundles. State changes include:

p� Draft: The initial draft of the requirement has been developed by the BA. In this state, the requirement can only be viewed by the author and admin users.

p� Active: The requirement can be viewed by all project contributors and stakeholders, but it has not yet been approved by relevant stakeholders. The requirement may still undergo a lot of change until it reaches the next state.

p� Approved: The requirement has been reviewed and approved by the related Feature Business Owner. The requirements for that set of features are complete.

p� Designed: The detail of the requirement has been fleshed out, including all field entries, attributes, and visualizations.

p� Bundled: The requirement has been grouped with other requirements into a bundle. However, the bundle has not been approved and finalized.

p� Descoped: It has been determined that the requirement does not fit into the current project’s scope. However, the record may still contain valuable information that will be useful in other projects, so the record remains visible to their authors and admin users.

Process1. Develop the non-functional requirement statements. The information regarding structure

and word choice on page 41 is also applicable to these requirements.

2. Enter non-functional requirement statements into RequirementPro™. Requirements can be entered into the application in two different ways: either individually, from the Non-functional Requirements index, or en masse, from the related feature. Refer back to page 43 for instructions on entering requirements into RequirementPro™. Later, users with a Portfolio Subscription have the ability to apply a pattern to the requirement so that it’s easier to elaborate with the correct details (refer to Chapter 6: 5.6 Elaborate with Additional Details for more information).




3. Obtain approval of the Non-functional Requirements set. Ensure the Sponsor for each Non-functional feature has reviewed and approved the related requirements to check for two things:

p� That the set of requirements is complete.

p� That the individual requirement statements are correct and well written.

Ask reviewers to weigh requirements against the checklist below. For descriptions of all of these quality characteristics, refer back to page 45.

p� Accurate

p� Atomic

p� Complete

p� Modifiable

p� Practical

Areas to Consider for Non-Functional RequirementsThis list is provided to give you an idea of the different areas which may have related non-functional requirements. When documenting these requirements, ensure the following areas are covered, if they are applicable to your project:

p� Accessibility

p� Accuracy

p� Adaptability

p� Appearance

p� Availability

p� Backup and Restore

p� Capacity (current and forecast)

p� Certification

p� Compliance

p� Compatibility (Platform, Database, etc.) Concurrency

p� Configuration Management

p� Deployment

p� Documentation

p� Disaster Recovery

p� Efficiency (Resource Consumption for Given Load)

p� Effectiveness (Resulting Performance in Relation to Effort)

p� Emotional factors (e.g., Fun or Absorbing)

p� Environmental Protection

p� Error Handling

p� Escrow

p� Exploitability

p� Extensibility (Adding Features, and Carry-forward of Customizations at Next Major Version Upgrade)

p� Failure Management

p� Installability

p� Interoperability

p� Maintainability

p� Performance

p� Reliability

p� Reusability

p� Security

p� Supportability

p� Usability

p� Understandability




Comprehension Exercise: Is It Functional or Non-functional? This exercise will help business analysts improve their skills in identifying non-functional requirements. Determine whether each requirement below is either a functional or non-functional requirement. The answers are provided on the next page.

1. System shall allow electronic retrieval of results.

2. System shall display a clock rate within 5 Hz of the actual clock rate.

3. System shall have the ability to schedule appointments for multidisciplinary clinic providers.

4. System shall be able to change the indicated gender of the client.

5. System shall allow the UI language to be switched from English to German without recompiling or rebuilding.

6. System shall return to a functioning state during a system restart.

7. System shall support trending and graphing of results information.

8. System shall consume a maximum of 16 Mbytes of memory.

9. System shall allow 100,000 checks processed per hour.

10. System shall alert care providers to past-due assessments and documentation.




Answers

1. Functional

2. Non-functional

3. Functional

4. Functional

5. Non-functional

6. Non-functional

7. Functional

8. Non-functional

9. Non-functional

10. Non-functional

Related Content in RequirementCoach™Practice Aid: Non-functional Requirements Elicitation Question Bank: A major step in preparing for requirements elicitation is determining what questions need to be asked. Without a prepared document listing the requirement questions you will need, elicitation sessions can veer off course or suffer from silence. Either way, this is valuable stakeholder time that you do not want to waste. Requirement questionnaires can be integral to keeping elicitation sessions on track and productive.

Wiegers Training: Video 14. Non-Functional Requirements: In this video, Karl Wiegers discusses the most commonly discovered types of non-functional requirements.


Create Requirement Visualizations

5.5 Chapter Five



IntroductionTraditionally, in requirements development, a lengthy requirements document is produced after many individual and group interviews are conducted. Then, the requirements document is given to the design team to create a functional design that developers use to write code. This method often yields results that are different from what the business envisions. Using requirements visualization techniques can significantly reduce this problem.

According to requirements authority Alan Davis, no single view of the requirements provides a complete understanding. You need a combination of textual and visual requirements representations to paint a full picture of the intended system: diagrams communicate certain types of information more efficiently than text; pictures help bridge language and vocabulary barriers between different team members; and videos are helpful to capture interviews and decisions. This chapter provides concise descriptions of various techniques that may be used for requirements visualization. More in-depth descriptions, instructions, and examples of each technique can be found in the Visualization Methods series on www.RequirementCoach.com.

Chapter Five: Create Requirement Visualizations



Core Concept: Requirements VisualizationRequirements visualization has many different meanings. Some view it as supplementing textual requirements with graphical illustrations and others view it as a form of user interface (UI) prototyping that is used for gathering customer requirements. The second definition is too limiting and focuses only on UI, totally ignoring other key considerations, such as the business process, background processes, etc. UI prototyping is important but should be considered as only one type of requirements visualization methods. It’s important to recognize there are many different types of requirements visualization.

The purpose of a visualization is to communicate data to a specific audience that usually consists of the technical and business stakeholders related to the project. Think of requirements visualizations as a facilitator to initiate a better degree of communication and understanding between project contributors, developers, and other project stakeholders. Regardless of the methods you select, visualizing your requirements will provide valuable benefits:

p� Missing requirements are easy to spot.

p� Understanding of requirements is increased.

p� Understanding of the dependencies between requirements is increased.

p� Mistakes are easy to identify.




Types of VisualizationsThe table below includes concise descriptions of various techniques that may be used for requirements visualization. The Enfocus Requirements Suites™ provides the ability to attach and share these methods of visualization, so they are always available to ensure complete understanding by users, stakeholders, and developers. We’ve divided the most common requirements visualization techniques into six different classifications to help you determine which techniques are best for the project at hand: data, process/workflow, concepts, user interface, UML models, and other.

Data

These diagrams are mainly used to describe data, their attributes, and their relationships.

Database Diagrams

Other terms for this technique are database schema and entity relationship diagram. Database Diagramming is a technique for database design and development that allows you to create a clear database structure. A database diagram provides a complete understanding of all tables, their relations, and how to store them. This technique is simple and easy to understand with minimal training, making it a great tool for communicating design to end users.

Entity Relationship Diagrams

According to the book, Business Analysis Techniques, an entity relationship diagram or model is a conceptual representation of the main data items (known as entities) used within an organization and held within a software system, and of the relationships between entities. This visualization method provides the BA with an understanding of the data that is used within the organization, as well as a view of requirements from a top-down perspective.




Process/Workflow

The visualizations in this group are most often used to describe various perspectives of business processes.

Business Process Model and Notation (BPMN)

Business Process Model and Notation (BPMN) is a standard developed by the Business Process Management Initiative (BPMI) for business process modeling. Business analysts and managers who are seeking to improve process efficiency and quality typically find this models useful. This technique provides a graphical notation for specifying business processes, ensuring that both technical users and business users can understand the complex process semantics. BPMN is a common language that bridges communication gaps, which often occur between business process design and implementation.

Cycle Diagram

A cycle diagram is a simple technique that can be used to illustrate the phases of a process. Cycle diagrams represent continuing sequences of stages, tasks, and events in a circular flow. Depending on how the diagram is intended to be used, the BA will usually emphasize either the stages and steps or arrows and flows.

Data Flow Diagrams

According to Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines, a data flow diagram (DFD) is a popular technique developed for structure analysis and design. A DFD displays the flow of data from external entities into the system, how the data moves from one process to another, and the logical storage of the data. DFDs are often used to create an overview of the system before developing a more elaborate visualization.

FlowCharts A flowchart is a diagram that displays the sequencing of activities in a process, the participants responsible for each activity, and the artifacts used during the process. According to Howard Podeswa in The Business Analyst’s Handbook, this technique is commonly used to analyse the impact of change on end-to-end business processes. It is also used to model user interactions in requirements.

Value Stream Maps

Value Stream Mapping is a powerful technique based on “lean” manufacturing principles that can help organizations evaluate the current state of products or services that may not be performing optimally and develop a plan to lead to the desired future state. A value stream can be defined as all activities—value-added and non-value-added—that are required to bring a product or service from raw material to the customer. A Value Stream Map (VSM) is a visual baseline to identify process improvement opportunities—both quick, practical solutions and long-term solutions—as well as the possible need for a Six Sigma approach when “lean” solutions aren’t applicable because a root cause cannot be identified. A VSM also provides insights into prioritizing improvement efforts, modeling, planning, and implementing the future state, as well as evaluating process improvement effectiveness.




Concepts

This group of visualization techniques is commonly used to describe various concepts, and can be used in many contexts.

Ansoff Matrix

Mathematician Igor Ansoff developed a matrix that is useful in portraying corporate growth strategies by focusing on the organization’s present and potential products and markets. By presenting four possible product-market combinations, the matrix helps the BA to consider ways the organization can grow via existing and new products, and in existing and new markets. The four possible growth strategies suggested by the matrix include Market Penetration, Market Development, Product Development, and Diversification.

Concept Mapping

Concept maps, or concept diagrams, can be used to provide informal and high-level representations of business processes within an enterprise. Concept mapping is also a useful technique for communicating, brainstorming and exploring. Generally, the purpose of concept mapping is to outline relationships between ideas by using a hierarchical tree structure which branches out to illustrate the concepts and provide an understanding of their relationships. In comparison to UML Modeling or ERDs, concept mapping is often accepted in the business community because of the ease with which an individual can understand the map’s concepts and relationships. According to Thomas Frisendal in Design Thinking Business Analysis: Business Concept Mapping Defined, concept maps are to a BA what snapshots, sketches, and cardboard models are to a building architect.

Decision Trees

A decision tree is a decision support tool that uses a tree-like graph or model to show decisions and their possible consequences, including chance event outcomes, resource costs, and utility. Decision trees are commonly used in decision analysis to help identify a strategy to reach a goal. Another use of decision trees is as a descriptive means for calculating conditional probabilities.

Logic Gate Diagram

The logic gate diagram provides a description of a logic gate. A logic gate is a type of circuit that regulates the flow of electricity that determines the Boolean logic computers use to make complex logical decisions. The seven basic logic gates are AND, OR, XOR, NOT, NAND, NOR, and XNOR. A logic gate diagram may be required to complete design.




Concepts Cont.

Mind Maps Mind maps are diagrams that are used to represent words, ideas, tasks, or other items linked to and arranged around a central key word or idea. By presenting ideas in a graphical, non-linear manner, mind maps encourage a brainstorming approach to planning and organizational tasks. Mind map diagrams have a basic tree format, with a single starting point in the middle that branches out, and divides again and again. The tree is made up of words or short sentences connected by lines. The lines have meaning as well, signifying a relationship between two entities. This technique is useful in any stage of the project where brainstorming takes place.

Spider Chart A spider chart is a graphical way of comparing data that is displayed in a “web-like” form. This technique is used to evaluate multiple alternatives based on multiple criteria. Spider charts are particularly useful when developing business requirements and when comparing the performance of vendors.

Whiteboards Whiteboards, also referred to as marker boards or dry-erase boards, are glossy, usually white surfaces that allow rapid non-permanent marking. Whiteboards are a useful brainstorming and modeling tool. There are now many software tools on the market that can also perform this function.

User Interface

These visualization techniques were specifically developed the user interface of the software solution.

Rapid Prototyping

Rapid Prototyping, also referred to as rapid development, is the activity of quickly creating models of software applications with very little pre-planning. The purpose of this technique is to fabricate a scale model of the application that can be used to finalize the requirements of the solution. Rapid prototyping aids in visualization, decreases development time, and increases effective communication.

Rapid Prototyping

Rapid Prototyping, also referred to as rapid development, is the activity of quickly creating models of software applications with very little pre-planning. The purpose of this technique is to fabricate a scale model of the application that can be used to finalize the requirements of the solution. Rapid prototyping aids in visualization, decreases development time, and increases effective communication.




Site Map A site map is a diagram displaying the website architecture to be implemented. Site maps are commonly used before or in tandem with developing wireframes. Both techniques offer the same information, but from two different perspectives. Starting with a site map will help the team determine how many basic pages are needed, and whether these pages need to be broken down.

Storyboard A storyboard is a technique consisting of a series of diagrams or screen sketches showing navigation routes through a task or a series of screenshots. Storyboards are helpful to illustrate the structure and navigation of a system, and are often used to obtain feedback from interested parties. This technique assists in understanding the big picture and breaking it down into smaller components that are easier to focus on. While storyboards are similar to prototypes, the advantage here is storyboarding can be done quickly with a pencil and paper and without the use of technology.

UI Mockups Software User Interface (UI) Mockups have the appearance of the final solution, but do not function beyond what the user sees. In contrast, a prototype will work like the developed solution. UI mockups can range from simple, hand drawn screen layouts, through realistic bitmaps, to semi-functional user interfaces developed in a software development tool. Balsamiq is one tool that the analysts at Enfocus have found useful for mockups.

WireFrames Wireframes, also known as page schematics or screen blueprints, are used to depict the page layout or arrangement of content on a computer screen or website. They show interface elements, navigational systems, and how those components work together. With wireframes, the focus is on what the screen does, not what it looks like. The most important elements are functionality, behavior, and priority of content.




Unified Modeling Language (UML) Models

This technique consists of various types of models that adhere to a standardized unified modeling language (UML), which is maintained by the Object Management Group. UML provides standards for application structure, behavior, and architecture, and includes a set of graphic notation techniques to visualize, modify, construct, and document requirements of an object-oriented software-intensive system. UML modeling provides standards for the three types of visualizations: Structure Diagrams, Behavior Diagrams, and Interaction Diagrams:

Structure Diagrams

Structure Diagrams are the most widely used of the UML models. These diagrams emphasize what must be present in the system, and are often used in documenting software architecture.

Class Diagram

A class represents an object or set of objects that share a common structure and behavior. Classes refer to either one of two concepts:

p� The components of a software system.

p� The workers and artifacts of an organization.

Class diagrams display the classes in a system, the attributes and operations for each class, and the relationships between classes.

Component Diagram

A component diagram displays the structural relationship of the components within a software system. This technique is most commonly used when the project involves complex systems with many components. In addition to the components, the interfaces between each component are described using different types of connectors.

Composite Structure Diagram

These diagrams describe the internal structure of a class and the collaborations that the structure makes possible. Composite structure diagrams consist of structured classifiers, parts, ports, connectors, and collaborations.

Deployment Diagram

Deployment diagrams describe the hardware used in system implementations and the execution environments and artifacts deployed on the hardware. This is a useful technique when a software solution is being deployed across multiple machines with unique configurations. Deployment diagrams describe the hardware being used and the interaction between the processor and other components. Generally, these diagrams are developed at the beginning of design to determine the necessary hardware configuration.




Structure Diagrams Cont.

Object Diagram

Object diagrams are similar to class diagrams in that they display the relationships between objects. However, the difference is that object diagrams describe a complete or partial view of the structure of the system at a specific time by using real world data. This technique is most often used to show examples of data structure.

Package Diagram

Package diagrams describe the dependencies between different packages in a system. A package is a group of UML elements that are grouped together according to related semantics. Package diagrams can be used to represent the different layers of a software system, illustrating the system’s layered architecture.

Profile Diagram

Profile diagrams are developed to augment the standard UML metamodel to meet the requirements of a specific domain. Profile diagrams are rarely used and were recently introduced in UML 2 to display the usage of profiles. Profiles describe lightweight, generic extension mechanisms that can be used to customize UML models for specific domains and platforms. An extension mechanism is something that allows standard semantics to be defined in a strictly additive manner, so that they do not contradict standard semantics.

Behavior Diagrams

These diagrams depict the behavioral features of a system. Behavior diagrams may refer to Activity, State Machine, or Use Case Diagrams, as well as the four interaction diagrams described in the next section. These diagrams are typically used to describe the functionality of software systems.

Activity Diagram

Activity diagrams are used to describe the business workflow or operational workflow of any component of a system. These diagrams provide support for choice, iteration, and concurrency. The purpose of this technique is to display the overall flow of control. An alternative to activity diagramming is the UML state machine diagram.




Behavior Diagrams Cont.

State Machine Diagram

Sometimes referred to as a state chart or state diagram, a state machine diagram describes the states and state transitions of a system. The main differences between the state machine diagram and activity diagram are the notations and usage changes. These diagrams are useful in describing the behavior of objects that act differently according to the state they are in at the moment. There are two types of state machines: the behavioral state machine can be used to model the behavior of individual entities, and the protocol state machine is used to express usage protocols and can be used to specify the legal usage scenarios of classifiers, interfaces, and ports.

Use Case Diagram

The most commonly used behavioral UML diagram is the use case diagram. Use case diagrams provide a graphic overview of the actors involved in a system, different functions required by the actors, and how the different functions are interacted. This technique is useful for focusing on the “what” and not the “how.”

Interaction Diagrams

Communication Diagram

A communication diagram, formerly referred to as a collaboration diagram, is similar to a sequence diagram but the focus is on the messages passed between objects. Generally, communication diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system.

Interaction Overview Diagram

This diagram provides an overview of a system in which the nodes represent communication diagrams or one of the other types of interaction diagrams. Interaction overview diagrams are most often used to understand complex scenarios that would otherwise require complicated paths to be illustrated in a single sequence diagram.

Sequence Diagram

Sequence diagrams describe how objects interact and the order in which they interact for a particular scenario. These diagrams are commonly used in requirements development to refine use cases so that they can be used in system design.

Timing Diagrams

Similarly to sequence diagrams, timing diagrams represent the behavior of objects in a specific time frame. If more than one object is involved, the diagram will also describe the object interactions. The main difference between timing and sequence diagrams is that timing diagrams depict time from left to right. There are two types of timing diagrams: those with concise notation, and those with robust notation.




Other

Network Diagram

According to Scott Ambler and Mark Lines in Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise network diagrams are commonly used to depict hardware nodes and the connections between them. A network diagram displays the devices that enable a network (e.g., routers and switches) and the devices that access the network (e.g., PCs). Often, network diagrams are considered to be a high-level form of UML deployment diagrams. Hand drawn diagrams (like on whiteboards) are sometimes created before developing a more formal diagram with a drawing tool.

Organizational Chart

An organization chart is a diagram that visualizes the formal structure of an organization, the relationships among employees, and the relative ranks of their positions. While this is a simple technique, it is often forgotten or overlooked. An organizational chart is a useful tool for the BA to have at any stage in the project. It is especially useful in projects that cross a lot of boundaries, different divisions, departments, and managers. The BA should refer to the organizational chart during requirements development to ensure the appropriate individuals provide input and validate requirements.

PERT Chart A PERT (Program Evaluation Review Technique) Chart is generally a project management tool, but may also be used by the BA to schedule, organize, and coordinate tasks within a project, especially those involved in requirements management and solution assessment and validation. The PERT chart is often useful planning testing and building activities. PERT charts can be used to determine the project’s critical path, which is the sequence of stages that determine the minimum amount of time required for the project to be completed.

Work Breakdown Structure

Another project management tool that can be used by the BA is a work breakdown structure (WBS). This technique helps manage complex projects by breaking it down into individual components in a hierarchical structure. A WBS often proves useful when determining the requirement bundles, the work schedule, and the developers responsible for building the solution.




Process in Enfocus Requirements Suite™The process for using visualizations in Enfocus Requirements Suite™ is very simple. With so many great visualization tools in the market today, Enfocus Solutions does not intend to throw another option in the ring. Instead, we suggest you select your favorite visualization tools to use, and attach the finished documents to the related records in RequirementPro™. There are two different ways you can insert visualizations into the application. We suggest choosing the method that works best for your organization depending on whether the document will change often or stay the same.

1. Hyperlinks.

If the visualization tool that you are using allows you to share your documents, we suggest using hyperlinks to keep all of your requirements information in one place. A hyperlink is a link from a text file to another location or file, and can be added to any text box editor in RequirementPro™ and StakeholderPortal™. This method is useful in situations where the visualization isn’t finite and is still going through changes.

To create a hyperlink on a requirement record, first type the title or identifier for the visualization in the text box on the Edit page. Then, highlight the text and click the Insert Hyperlink button (The icon is a chain with a plus sign). After copying and pasting the link, submit the hyperlink and save the requirement.




After saving the record, all project contributors and stakeholders will have access to the visualization, as displayed in the screenshot below. Clicking the link will bring the user to the document stored on your external visualization tool.

The analysts at Enfocus Solutions have found a lot of success with applications like Creately (www.Creately.com), a visualization tool that allows for online collaboration. For teams that need to collaborate, but can’t get in the same room to do so, hyperlinking to documents like those made in Creately provides a way for all project contributors to be able to edit and/or view the visualization. One great thing about Creately is that the application allows the author to choose whether s/he wants other people to have the ability to edit the visualization, or only view it.

Tip




2. Attachments.

Another way to ensure your requirements have the visualizations they need is to attach documents to the individual records. To add an attachment to a requirement, click the New button, provide a Name, and select the file. Optionally, you may want to add a description.

To view the description of a saved attachment, click the View button. This is also where project contributors and stakeholders can add comments. After saving the file, the attachment will appear on the requirement you attached it to, as well as the Project Attachments index found underneath the Dashboard tab. These attachments can be accessed in both RequirementPro™ and StakeholderPortal™.




Task Completion CheckpointIt is difficult for the BA to determine that Task 5.5 Create Requirement Visualizations has been completed and adequately performed. Remember that it is possible that this task is performed concurrently with other tasks in the same task group. Before moving onto Task Group 6.0 Requirements Management, the project team should review all requirement records in RequirementPro™ to ensure there are no missing visualizations. Also, it is good practice to review the documented visualizations with the appropriate technical and business stakeholders to ensure they correctly reflect the information being conveyed. Since the purpose of requirements visualizations is to convey a message to project stakeholders, it’s important that the BA collaborates with those stakeholders on building and revising the visualizations to ensure the solution is developed successfully. Before moving onto the next task group, ensure this checkpoint has been completed.


Elaborate with Additional Details

5.6 Chapter Six



Chapter Six: Elaborate with Additional Details

p� Customers are extensively involved

p� Developers have considerable domain experience

p� Precedents are available

p� A package solution will be used

p� Development will be outsourced

p� Project team members are geographically dispersed

p� Testing will be based on requirements

p� Accurate estimates are needed

p� Requirements traceability is needed

Less Detail More Detail

IntroductionCreating good requirements involves determining your project’s appropriate level of detail, which can often be tricky. Providing too little detail creates ambiguity that can negatively affect good requirements, but providing too much detail can be a downfall as well. Time spent providing excessive, unnecessary detail is time wasted—time that could have been better spent elsewhere. A balance between too much detail and too little detail is necessary, but more often than not, considered too late to be helpful. Waiting until after you find your requirements to be lackluster, poorly defined, mistake-ridden, or financially questionable to find a balanced level of detail can prove to be a major set back.

Knowing the right level of detail to provide about requirements is a necessary skill that successful organizations have. These successful organizations usually find that the flexibility afforded by their level of detail gives them the agility they want. The type of project being undertaken will help to define a loose balance of how much detail to use.



Core Concepts

Requirement Patterns

A requirement pattern is a template and guide to writing a particular type of requirement such as performance, archival and storage, report and query, etc. Each different pattern included the Portfolio™ Performance Subscription specifies what information should be gathered for that type of requirement, what to record, and what to focus on. Patterns are only included with the upgraded subscription; however, users with the basic Team Performance Subscription can use this chapter as a guide for what to put in the descrption field of a requirement. The concept of a pattern is quite simple—they are used to write strong individual requirements. Each pattern contains precise and specified low-level data that needs to be collected based on the type of requirement.

Software systems expert Stephen Withall first introduced the idea of requirement patterns in his book, Software Requirement Patterns. According to Withall, a high percentage of the features found in any commercial system are common to any other kind of system, and only a relatively small percentage of requirements differentiate systems for different purposes and industries. In studying requirements specifications over a variety of projects, Withall noticed that up to 50% of requirements written were common to all projects. He realized that developing requirement patterns could save project teams and business analysts significant effort and improve the quality of the requirements.

The over all aim of requirement patterns is to enable the business analyst to write higher quality requirements more quickly and with less effort. Better requirements are written because issues are pointed out that prevent the analyst from overlooking important elements.

Using patterns allows the business analyst to write requirements quickly and easily by providing an advanced starting-point; the business analyst begins with a substantially written requirement, rather than having to start from scratch. Some patterns—especially the complex ones—provide step-by-step instructions to follow when gathering the information you need.




Attributes

Attributes are unique, identified items directly associated with a requirement. When combined with requirements, they help make up requirements specifications. Attributes are often compared to children in parent-child requirement relationships.

As the last step in the requirement detail process, attributes are attached to a requirement to make it 100% complete. Attributes are additional characteristics of a requirement that are needed to ensure all details are provided to the design team. If a seemingly non-functional requirement is not independent of other requirements, then it is probably an attribute of another requirement.

Non-functional requirements can be considered attributes of other requirements. For example, the functional requirement, “Shall create trouble ticket,” would include the attributes, “The trouble ticket name must be stated first,” “Identification number must be stated after ticket name,” etc. Making these small specifications or tasks into attributes instead of separate, non-functional requirements helps the project team ensure that requirements are organized and easy to work with.

In addition to non-functional requirements, attributes can be used to define acceptance criteria. For example, if the requirement read, “Flickr users shall be able to assign different privacy levels to photos,” then the attributes could include:

p� A user cannot submit a form without completing all the mandatory fields.

p� Information from the form is stored in the registration’s database.

p� Protection against spam is working.

p� Payment can be made via credit card.

p� An acknowledgment email is sent to the user after submitting the form.

Requirement attributes also make the testing process easier by allowing the business analyst to check off attributes as their testing is completed. However, the largest benefit of attributes is that they remove ambiguity from requirements and provide the project team with the clearest picture possible of the solution requirements. There are multiple categories of attributes, which will be detailed in the Process section of this chapter.

Requirements Development is Iterative and Incremental

Requirements development is iterative because requirements can be constantly updated and edited after meetings with stakeholders and taking stakeholder comments into consideration. Requirements development is incremental because requirements are made according to a thought out, step-by-step process. Enfocus Solutions Inc. suggests detailing and fleshing out your requirements using the process described on page 65.




Requirements Evaluation According to INVEST

Recall from previous chapters that requirements should be evaluated according to the INVEST acronym principles written by XP employee, Bill Wake. Each letter in the mnemonic serves as a reminder of qualities a good requirement will have:

Independent— An independent requirement is not dependent on any other requirements in any way.

Negotiable—A negotiable requirement may always be edited and changeable.

Valuable—A valuable requirement will always bring value to the end user.

Estimable—An estimable requirement’s size is estimable.

Sized correctly— A requirement must be sized correctly so that it is not too much to write or plan.

Testable/Traceable— A testable requirement must detail all information and data necessary for test development.

Just in Time

The concept of “Just in Time” (JIT) development has been applied to manufacturing for several decades. This is the practice of providing just enough detail, just in time for development. Adjustments are made from project to project to employ JIT in the most effective manner, while some projects would fall apart using JIT simply because they require large and carefully calculated amounts of detail. Regardless of the project though, providing too much detail is wasteful and time consuming, and providing too little detail often results in significant rework and forces developers to make incorrect assumptions.

Development teams employing JIT capture requirements at a high level and on a gradual basis, just in time for each feature to be developed. The requirements produced will barely be sufficient; that is the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimize time spent on anything that doesn’t add value to the end product. For example, if you’re willing to defer many of the ultimate decisions about product capabilities and characteristics to the developers, you don’t need to include as much information in the requirements documentation. However, if you want to describe exactly what you expect to be delivered, more complete specifications are necessary.

As with many decisions made on software projects, balancing cost and risk is essential before undertaking JIT. It costs more to develop requirements in greater detail than to leave them more high-level, yet choosing the appropriate amount of detail to include depends upon how risky it is to leave decisions about requirements specifics to developers to make later in the development cycle.




People Who Define Requirements Do Not Always Define Attributes

Requirements are general and tied to business functions, whereas attributes consist of a lower level of detail and will likely be defined by software designers or developers. A large part of requirements involves stakeholder input and collaboration, so it makes sense that requirements would handle the business functions. Attributes, however, are more aimed towards software developers or designers because they involve technical and in-depth levels of detail from a variety of viewpoints often not thought of by stakeholders.




ProcessThe diagram below offers a comprehensive display of what detailing functional requirements entails and how those requirements are then sorted, augmented by additional reference documents, and broken into attributes. Parts of the diagram will be explained in detail further on in this task, but the Requirements Detail Diagram gives an organized overview of that process.

The teal boxes represent the process of detailing a functional requirement, while the green boxes represent processes that will remain ongoing throughout the entirety of the detailing requirements process. Aspects from the topics in the purple, green, and red boxes are combined initially to create a functional requirement that adheres to INVEST principles (independent, negotiable, valuable, estimable, sized correctly, and testable/traceable). Requirement patterns are then identified and their data is entered into RequirementPro™ if patterns are available with your subscription. Reference documents are then attached in the form of attachments and visualizations, and lastly requirements attributes are formulated.


Business Requirement Feature

Stakeholder Requirement Scenarios, Needs

Technical Stakeholder Comments

Related Business Rules Dependencies

Related Use Case

Attachments

Data Elements State TransitionMessage Formats Computations

Methods & Actions UI AttributesError Messages Task Sequence

Data Edits Exception HandlingControls Decision Tables

Search Criteria Data AccessSort Criteria Navigation

Visualizations

Acceptance Criteria

Business Stakeholder Comments

Functional Requirement

INVEST

Requirement Attributes

(Specifications)

Requirement Pattern

Reference Documents



Requirements Detail Diagram

Elaborating your requirements with additional details is a best practice recommended by the business analysts at Enfocus Solutions Inc. The key process steps for detailing a functional requirement are as follows:

1. Review and edit requirement.

2. Identify pattern.

3. Input pattern into Portfolio™ Performance Subscription version of RequirementPro™.

4. Provide references and attachments.

5. Add attributes.

6. Review attributes.

1. Review and Edit Requirement. Review you current requirement, and make any necessary changes to ensure it is complete and concise. Using information learned in Task 5.3 Document Functional Requirements, ensure that the requirement adheres to INVEST principles.

2. Identify Pattern. The next step is to identify which pattern correlates to your requirement. Patterns are a feature offered in the Portfolio™ Performance Subscription, but even if the business analyst doesn’t have access to the Portfolio™ Performance Subscription, it is recommended that the information provided about patterns in this guide is used to supplement functional requirements. There are efficiencies to be gained from using requirement patterns. Requirements developed with requirement patterns are more complete, ensuring key information is not overlooked. Each requirement pattern type has a template associated with it, which guides you to collect individually specified information depending on the type of the requirement.

Types of Requirement Patterns

p� Analytical Report and Query p� Archival and Storage p� Documentation p� Infrastructure p� Interface p� Operational Report and Query p� General Functionalp� Security and Access Control p� System Connectivity p� System Data

p� Transaction




Non-functional Requirements

p� Availability

p� Business Continuity

p� Compliance

p� General Non-Functional

p� Interoperability

p� Maintainability

p� Performance

p� Usability

Common Fields

Each unique requirement template contains general information in addition to its unique fields. You should complete the following fields for every requirement:

p� Name—Each requirement should have its own unique, concise, and specific title.

p� Reference Number—Reference numbers are automatically assigned to requirements as they are added to RequirementPro™. Having a unique reference number for each requirement to ensures it can be easily located.

p� Priority—The priority level is one of the most important pieces of information, providing the business analyst with an idea of the features that need to be implemented first.

p� Feature—Every requirement must directly relate to a feature already defined by the project team. If your requirement does not address a feature, it does not belong in the current project.

p� Description—Provide the details necessary to make the requirement complete.

In addition to the above fields, each template in RequirementPro™ has a unique set of fields where specific information should be entered to make the requirement complete. The following list is a description of the components of each pattern template included in Enfocus Requirements Suite™, organized according to type of requirement:




Functional Requirement Patterns

Analytical Report and Query

Analytical Report and Query requirements allow the user to analyze data that has been recorded.

Language—Specify the language of the report (for example, English, Spanish, Portuguese, etc.). In large companies that span continents, this might be an important field.

Report Type—State the type of report. Examples include dashboard, scorecard, report, query, or cube.

Report Content—Provide an extensive description of the data elements that must be in the report.

Format—Describe exactly how the document needs to be formatted. Documents require different formats depending on the location of distribution.

Standards—List any business rules or industry standards that must be followed in the report.

Sort Sequence—State the manner in which the report will be sorted: alphabetically, by invoice number, etc.

Selection Criteria—Specify whether there are any criteria needed for limiting data. For example, should the report just pertain to your region or just your stakeholder persona perspective?

Security and Privacy—Specify whether there are any security or privacy concerns with the report.

Distribution—Describe the method of distribution, which will have an effect on the format of the document. For example, will the document be published on a website? Printed in handouts?

Frequency—State how often the report is needed. For example, will it be only on demand? Will it be scheduled monthly?

Target Audience—Describe the audience that will be reading the report. For example, is it intended for managers? Transaction users?




Archival and Storage

Archival and Storage requirements allow the user to record how long a particular record will be available, including legal obligations or accounting rules, and the method used to store this information.

Retention Period—Specify the length of time in which the information is to be stored.

Accessibility—Specify the method in which the information is to be accessed once the data is archived.

Security—State who will be allowed to access the archival and storage information.

Standards—List any business rules or industry standards relevant to archival and storage.

Archival Method—State the method used to store the information.

Documentation

Documentation refers to requirements that help outline the purposes and required content for creating a new document.

Language—Specify the language of the document (for example, English, Spanish, Portuguese, etc.). In large companies that span continents, this might be an important field.

Purpose—State the reason for the new document. For example, a support team for a new business might need a manual written to make their tasks easier to learn.

Content—Determine and describe the content needed in the new document.

Format—Describe exactly how the document needs to be formatted. Documents require different formats depending on the location of distribution.

Standards—List any corporate policies or industry standards that must be followed in the document.

Availability—State where the document is to be available. Will it be available on a web page or does a user have to download it?

Distribution—Describe the method of distribution, which will have an effect on the format of the document. For example, is the document intended to be published on a website or printed in handouts? Also, state to whom it is being distributed. For example, is it going to be delivered to managers only or every employee?

Confidentiality—State whether the document should be distributed to all external customers or internal users only.




General Functional

The general functional pattern isn’t necessarily a pattern, but still includes the basic fields for those requirements that won’t fit into any other functional requirement pattern in RequirementPro™. General functional requirements should have detailed and informative descriptions.

Infrastructure

Infrastructure requirements are related to the software platform or specific hardware and can be performance related.

Quantity—State how many items are needed. For example, how many servers, desktops, or routers will the system require?

Date Needed—State the date when the infrastructure items are needed.

Reason—Describe why the infrastructure is needed.

Specification—State technical specifications for items. Example considerations include the amount of memory, number of ports, speed, etc.

Infrastructure Type—State the type of infrastructure. Examples include network equipment, desktops, storage, servers, middleware, or DBMS.

Interface

Interfaces are requirements describing the exchange of messages and the points of interaction between two software systems. (Note: while some BAs believe these to be non-functional requirements, we categorize them as functional requirements.)

Source System—Describe the originating location of the interface.

Target System—Describe the location to where the data will be sent.

Purpose—Describe why the interface is needed.

Information to Pass—Describe which information is to be exchanged.

Message Format—Describe the format of the message to be exchanged.

Frequency—State how often the message will occur.

Technology—Specify whether any particular technology is needed for the requirement.

Standards—List any business rules or industry standards that must be followed in the interface.




Operational Report and Query

Operational Report and Query requirements describe a need for an operational report that is usually produced as part of a standard processing routine. Operational report and queries are usually performed daily, monthly, or quarterly. Examples include month-end financial reports, customer statements, purchase orders, trial balances, aging reports, and customer lists.

Language—Specify the language of the document (for example, English, Spanish, Portuguese, etc.). In large companies that span continents, this might be an important field.

Report Content—Provide an extensive description of the data elements that must be in the report. For example, if a report of all employee information is necessary, the report will require names, addresses, phone numbers, identification numbers, etc.

Format—Describe exactly how the report needs to be formatted. Reports require different formats depending on the location of distribution. For example, will it be displayed online or printed? After answering that question, should it be portrait, or landscape? Is a special form or image required?


Sort Sequence—Specify how the need will be sorted. For example, should it be alphabetically or by invoice number?

Security and Privacy—Specify whether there are any security or privacy concerns with the report.

Distribution—Describe the method of distribution, which will have an effect on the format of the document. For example, will the document be published on a website? Printed in handouts?

Frequency—State how often the report is needed. For example, will it be only on demand? Will it be scheduled monthly?

Target Audience—Describe the audience that will be reading the report. For example, is it intended for managers? Transaction users?

Report Type—State the type of the report. Examples include monthly reports, lists, aging reports, queries.




Security and Access Control

Security and Access Control requirements specify who is able to use and view information within the system.

User Registration—Specify the necessary process for adding a new user to the system.

User Authentication—Specify how the users are to be recognized by the system. For example, do they enter a user ID and password? How long should the password be? User Authorization—Describe the process for authorizing new users. For example, do they get set up automatically when they sign up, or does a department head have to approve them?

Access Approval—Specify the individual(s) who determine the roles people have and the data that each role has access to. For example, who can CRUD (create, read, update, and/or delete) records in the system?

Audit Controls—Describe the need for keeping track of when users last signed on and how that information needs to be tracked.

Data Security—State whether there is confidential data in the system and how to protect it. For example, how do you secure information about employee salaries and social security numbers?

Network Security—Describe any necessary network security such as encryption.

Transaction Security—State who is authorized to perform a transaction.


System Connectivity

System Connectivity requirements tie two systems together. These requirements are used frequently for EDI and other situations where two systems must communicate with each other, such as partners in supply chain management.

Source System—Describe the location where the data originates.

Target System—Describe the location to where the data will be sent.

Purpose—Describe why the connectivity is needed.

Technology—State the technology needed to connect the two systems. For example, do the systems require a network interface?

Throughput—Specify the rate at which the system should be able to perform an input or output processing.

Availability—Specify percentage uptime and hours of availability.

Security—State any special security needed to ensure secure connectivity.

Standards—State any rule or principle by which the requirement must abide.




System Data

System Data requirements define data to be stored and how to store it in the system.

Data Elements—Define individual data elements for the data entity. For example, for a customer entity, attributes might be customer number, name, address, phone number, category, past due status, etc.

Relationships—State any relationships between this data entity and other data entities.

Security—Specify any security requirements that are needed to control access to the data.

Usage—Specify how the data will be updated. This is usually done using a CRUD matrix.

Transaction

Transaction requirements describe business events, which can be measured in terms of money.

Trigger—State the event that initiates the transaction. Examples include a telephone call from customer, received purchase order, inventory levels dropping below a certain threshold.

Preconditions—State any preconditions that must exist for the transaction to function. Postconditions—State any postconditions that must exist for the transaction to function.

Output—Describe the output of the process. A common example would be a customer invoice.

Input—Describe the inputs needed to process the transaction.

Processing—Describe the procedures/steps that occur to process the transaction.

Internal Controls—Specify what internal controls must exist to prevent errors and fraud. List any audit findings that need to be addressed by the requirement.

Standards—List any business rules or industry standards that must be followed during the transaction.




Non-functional Requirement Patterns

Availability

Availability requirements address the availability of a system to its users.

Hours of Operation—Specify the hours the system is to be available. For example, will it be available 24 hours a day or only Monday through Friday from 7am-7pm?

% Uptime—Specify as a percentage the availability (usually expressed as 99.9%).

Maintenance Window—Specify the hours per week and the period of time when maintenance will be conducted. This is often expressed as 2 hours per week, 2 hours per month, etc.).

Business Continuity

Business Continuity requirements document how to continue operations in the event that there is a disruption in service.

Recovery Time Objective (RTO)—Specify the duration of time within which a business process must be restored after a disruption in service to avoid unacceptable consequences associated with the disruption.

Recovery Point Objective (RPO)—Specify the maximum tolerable period in which data might be lost from a service due to a major disruption.

Threat—Describe what could occur to cause a disruption in the service.

Impact—Describe the influence or effect the requirement will have.

Testing—Describe how the business continuity plan will be tested.

High Availability Architectural Requirements—State any architectural requirements needed for high availability.

Compliance

Compliance requirements help to ensure that any regulations from the business, government, or industry are documented and accounted for.

Version—If the need is a result of an updated regulation or standard, state the name of the most recent version so that there is no confusion among project contributors.

Type of Standard—Specify what government-mandated type of standard is addressed by the requirement. Examples include business, business best practices, etc.

Standards—List any corporate policies or industry standards that must be followed.

Purpose—State the reason why your organization must comply. For example, if it is not a law, are you contractually obligated?

Citation—Provide the page number or reference number associated within the standard. Be very specific in your citation. Provide the paragraph number to guide people directly to the standard to which you refer.




General Non-Functional

The general non-functional pattern isn’t necessarily a pattern, but still includes the basic fields for those requirements that won’t fit into any other non-functional requirement pattern in RequirementPro™. General non-functional requirements should have detailed and informative descriptions.

Interoperability

Interoperability requirements describe the ability of different systems to successfully work together without restricted access.

Type of Interoperability—Select the type of required interoperability: Information, Business, or Technical.

Purpose—Describe why interoperability is needed.

Data Exchange—Specify the data to be exchanged between systems.

Architecture—Describe the architecture required to make the two systems interoperable.

Security—Specify whether there are any security concerns within the interoperability.

Maintainability

Maintainability systems are often developed by contractors. Defining maintainability requirements is important when transitioning outsourced development to in-house maintenance resources.

Environment—Describe the environment in which the system will function.

Maintenance Organization—Determine how the performance of maintenance is to be organized.

Documentation—Describe the necessary documentation to successfully perform maintenance.

Architecture and Design—Determine how the chosen software architecture and design will affect the maintainability of the system.

Source Code—State whether the system must comply with coding standards; list the standards with which it must comply.

Test Cases—Describe the necessary related test cases that will reduce the risk of introducing faults when performing maintenance.

Process—Describe the process to facilitate maintainability.




Performance

Performance requirements document different aspects of performance, which is a measure of what is achieved or delivered by a system, person, team, process, or IT Service.

Batch Jobs—Determine the actions performed by the system without manual intervention.

Response Time—Specify how fast requests must be processed.

Throughput—Determine the rate at which incoming requests should be completed.

Concurrency—Determine the number of users that can work with the system simultaneously.

Scalability—Describe the ability of the system needed to meet performance requirements as demand increases.

Usability

Usability requirements outline necessary qualities of the system that contribute to the overall usability of the system, which is a measure of the system’s potential to accomplish the goals of the user.

Ease of Learning—Describe what is needed to make the system easy to learn for both novices and users with experience with similar systems.

Task Efficiency—Describe what is needed to make the system efficient for the frequent user.

Ease of Remembering—Describe what is needed to make the system easy to remember for the user.

Understandability—Describe what is needed to ensure the user understands what the system is intended to do.

Satisfaction—Describe what is needed to ensure the user is satisfied with the system.

Performance—Describe what is needed to ensure the system responds quickly to user requests.




3. Input Pattern. After familiarizing yourself with the pattern types and determining which pattern suits the requirement, gather the information required and fill in the specified fields using RequirementPro™. Patterns can be applied to requirements developed by users with a Portfolio Performance Subscription. They can only be applied to draft requirements, as seen in the screenshot below.




4. Provide References and Attachments. Next, reference and attach any related documents or visualizations. Related business rules, related use cases, related needs, and related scenarios are to be filled in at this time as well. Ensure that the requirement has been activated and note that only business rules, use cases, needs, and scenarios within the same feature as the requirement may be linked to your requirement using the Manage button.

After clicking the Manage button, link related articles by clicking the plus sign in the upper right hand corner of the business rule, use case, etc. that you would like to establish as related to your requirement as shown below.




To attach related documents and visualizations, go to the Detail tab of your requirement and scroll down to the Attachments section. Clicking the New button will expand that section and allow the business analyst to choose a file from their computer and enter an accompanying name and description as shown below. For more information on the types of visualizations to create and attach, see Chapter 5: 5.5 Create Requirement Visualizations.




5. Add attributes. Many projects will benefit from including attributes with their requirements; attributes are a useful for augmenting basic requirements and can be viewed as a further elaboration of the specifications presented in a requirement. To add attributes to your requirement, scroll to the Attributes section of your requirement from the requirement detail tab and click the New button.




Below is a list of attribute types that the business analyst will use to formulate attributes:

Methods and Actions: Attributes in the form of Methods and Actions are essentially UML Class Actions. A UML class represents abstract units such as things, roles, incidents, interactions, etc., and an action is the primary unit in a behavioral description, such as a UML state machine or activity diagram. Actions “do something” to work together and form the specifics of what the behavior does, so methods and actions attributes detail the smallest and most specific of methods and processes.

Error Messages: Attributes in the form of error messages define when an error will occur, and, if there is to be an error message, what the error message will say.

Data Elements: Data elements are data fields that go on a report and can be physically stored in a table. They are units of data that have specific meanings and precise semantics, and any data units defined for processing are considered data elements. Data elements may or may not consist of other data items. Often, in many record-keeping applications, data elements are combinations of bytes and characters that refer to separate items of data, like names, genders, ages, and addresses. Data element attributes are basic forms of information that have a unique meaning and distinct values necessary for your requirement.

To avoid miscommunications in naming data elements organization-wide, a glossary can be made for your data elements. Help for creating glossaries can be found in Task 4.4 Gather Business Rule and Task 4.5 Document Terminology.

Data Edits: Data edits are used to validate accuracy and can exist as either rules or attributes, but, essentially, data edit attributes lay out rules for editing data. Data might need to be edited before being presented, so editing ensures that the information provided is accurate, consistent, and complete. Data editing can be performed manually, through computer programming, or through a combination of the two.

Editing data can be done at the record level to detect errors in data through individual data records. At this point, the objective is to correct individual data records and determine the consistency of your data. You can also use data edits to assure data’s consistency by analyzing aggregate data (totals). Here, data is compared to data from earlier versions of the same data. This process helps to determine the compatibility of data.




There are several types of data edits available, including:

p� Validity You should use validity edits to look at one question field at a time. Validity edits are used to ensure record identifiers, invalid characters, and values have been accounted for. They also ensure that your essential fields have been completed and that specific measurement units have been properly used.

p� Range Range is similar to validity. While both look at one field at a time, this type of edit is used to ensure that your values, ratios, and calculations fall within your established limits.

p� Duplicates The business analyst may use duplication edits to examine records individually. Duplicate edits help you check for duplicated records and make certain that they have only been recorded once. They also ensure that the respondent does not appear in a survey more than once; this is especially true if there has been a name change. It also ensures that data has been entered into the system only once.

p� Consistency You can use consistency edits to compare different answers from the same record and ensure that answers correspond to one another. For example, if a person declares that they are in an under-21 age group, but later claims that they are retired; there is a consistency issue. Consistency edits can also occur as inter-field edits to assure that if a figure is reported in one section, a corresponding figure is reported in another.

p� History You can use historical edits to compare survey answers in current and previous surveys. This can include any dramatic changes since the last survey was flagged. Ratios and calculations can also be compared, and percentage variances that fall outside of established limits should be noted.

p� Statistics You can use statistical edits to look at entire sets of data. This edit type should be performed after all every other edit type has been applied and corrected. The data should be compiled and all extreme values and dubious data rejected.




Search Criteria: Search filters are search queries that are expressed as logical expressions. Search criteria also refers to how you would find data or sets of data in a data system and enable the BA to define search criteria and help provide more effective and efficient searches. Additionally, search filters are also helpful in locating multiple records.

A search filter should help to select subsets of investigation types from a database. Usually, BAs are only interested in one aspect of an issue. A filter should assist eliminating unnecessary data from a search by restricting searches or indexing by specific keywords that describe the type of search. A search filter is a combination of search terms, which must all be sensitive and specific for selecting relevant articles. If the filter is not sensitive, important articles may be missed. On the other hand, if a filter is not specific, search results can be irrelevant.

Sort Criteria: When working with sets of data, sorting helps arrange your data as needed. Sort criteria helps control the order in which results are presented. In general, sort criteria are specified by a direction. Also, the order in which something is sorted is important. For example, if a view is sorted by taxonomy term in ascending order, and then title in descending order, then the entire list of posts will be sorted by what taxonomy term they belong to. It is important to watch out for double sorting. Often times, using both Sort Criteria and Default Sorts in one field at the same time can give odd results.

Typical sort fields identified in sort criteria attributes are as follows:

Field—This simply says what field to sort by.

Order—Ascending order: Lowest value to highest value. Descending Order: Highest value to lowest value.

Option—An option that is specific to a given sort criteria.

Created Time—Sort by the submission date.

Last Updated Time—Sort by the last update date.

Title—Sort by the title, alphabetically.

Random—Searches will be ordered completely randomly.

Author Name—Allows you to sort alphabetically by author.

Last Comment Date—Allows you to sort by the date of the most recent comment.

Term Name—Sorts by taxonomy weight and name, as defined in the category administration.




Controls: Internal controls are the processes designed to help your organization accomplish specific goals and/or objectives within a system. Internal controls affect your organization’s structure, workflow, and information systems as a means by which your organization’s resources are monitored, directed, and measured. Internal controls are also necessary for detecting and preventing fraud while also protecting your organization’s intangible and physical resources.

Internal control objectives relate to financial report reliability, timely feedback on the achievement of operational or strategic goals, and regulation and law compliance. They also refer to actions that achieve a specific objective at a transaction level. For example, internal control procedures are used to reduce process variation and help provide more predictable outcomes. Within business entities, internal controls are also referred to as operational controls, and can also be implemented as business rules. A good example is: “Any credit card authorization over $100.00 needs a manager’s approval.

UI Attributes: User centered design attributes are attributes that address and help ensure better user experiences. Generally, user centered design refers to the interface designs and processes where the desires, limitations, and needs of expected end-users are focused on and given extensive attention during the design process. User centered design can be viewed as a problem solving process that tasks designers to predict how they expect people to use the product. It can also be used to test assumptions of user behaviors in real tests with actual users. User centered design testing is a necessity since it can be difficult for product designers to intuit the experiences of a first-time user or the first-time user’s learning curves. Specifications included in UI attributes include information like what font is to be used on a page, or what font size is to be employed under certain conditions.

Data Access: Data access refers to whatever kind of data is necessary to complete a function. Data Access attributes designate the rules and permissions needed for accessing a certain page or document. For example, “A user must be assigned privileges to access confidential data.”

Drill Down/Drill Across: Attributes associated with drilling up/down/across refer to the narrowing or widening of associations. Drilling down/up implies a parent-child relationship, whereas drilling across is associated with navigating from one sibling to another. When you drill down, you go through vertical hierarchies to find your data. As you drill down, you hide or toggle some items with others. If you need to drill across, it means you have to navigate across reports to find your data. In other words, if you feel the need to jump from one report to another, then you require the ability to drill across.

Exception Handling: Error handling details what will happen when a user receives an error. Consider the following questions when brainstorming exception-handling attributes: What data are you expecting that might not be there? How will you handle each instance of missing data? What happens if someone does something out of order? Or if they stop halfway through and then come back later? What happens if someone doesn’t have the data you are asking for? Can they move on or are they stuck? Enumerating error cases is a great opportunity to surface all of your assumptions, particularly around data needs, and how to resolve them if they are wrong.




State Transition: State transition attributes align with a UML State Machine. State Machine Diagrams describe the different statuses, or states, of an object and the events and conditions that cause an object to pass from one state to another. Attributes should describe the different states possible.

Computations: Computation attributes handle the computation of raw data. These attributes should define the different aspects being calculated, and their methods of calculation.

Task Sequence: The attributes describing task sequences align with BPMN diagrams and describe a specific sequence of steps to be completed. For example, “After an order is finalized the tax is to be calculated, and, lastly, billing info is to be collected.”

Decision Tables: Decision table attributes are literal decision tables submitted as attributes. Decision tables are used when there are certain conditions that must be evaluated and specific actions occur when those conditions are met. According to the book, Business Analysis Techniques, a decision table shows a set of conditions that may be combined in different ways in order to determine the required courses of action. Decision tables provide a clear and unambiguous means of documenting conditions and the resultant actions to be taken. In essence, decision tables are a compact way of representing a complete set of rules.

Navigation: Navigation attributes specify screen navigation processes. These attributes will detail buttons and where each button will lead.

Acceptance Criteria: There has been a lot of talk in the development community about acceptance criteria. Most teams realize that having clearly defined acceptance criteria before initiating development makes development a lot easier. Business analysts can use acceptance criteria to create better requirements, so accurately defining a client’s acceptance criteria is one of the most important elements of a successful development project. Microsoft Press defines acceptance criteria as “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Acceptance criteria has also been defined as “pre-established standards or requirements a product or project must meet.” No matter how they are defined, clearly delineated acceptance criteria are critical to project success.

Clients often have a hard time defining acceptance criteria at the start of a project. However, once the solution is delivered, clients seem to have no problem defining what is missing or wrong. Inaccurate or missing acceptance criteria can lead to low customer satisfaction levels, missed delivery dates, and development cost overruns, so it is critical to accurately define criteria before any development work begins.

Including acceptance criteria as part of the requirements documentation greatly enhances the likelihood of a successful project, so clearly defining acceptance criteria up front can avoid surprises at the end of a project and ensure a higher level of customer satisfaction. Take the time necessary to sit down with a client and determine what will define their project as successful and complete, and then track and report progress against those criteria to successfully develop and use acceptance criteria.




Acceptance criteria should be written from the perspective of the end-user or customer even though many teams leave development of acceptance criteria to QA. This is a bad practice and often leads to verifying that functionality built works rather than verifying that the functionality meets user needs and expectations. If you write and review acceptance criteria before implementation begins, it is more likely to capture the user intent rather than the development reality. Good acceptance criteria helps developers build the right solution, and are best delineated by business analysts during requirements development.

Guidelines for writing good acceptance criteria include:

p� Usability Be sure to include measures of usability in your acceptance criteria. In other words, you need to identify how to answer the question, “Is it easy to use?” Don’t just write, “Must be easy to use.” How are you going to measure this? For any given feature, we may measure ease-of-use by looking at the rate of successful use, setting an acceptable threshold. Or we might set a threshold for time to completion. The key is to identify the right measure or measures and to make sure each measure is readily quantifiable.

p� Functional Acceptance Criteria Identify specific user tasks, business processes or functions that must be in place at the end of the project. An example of acceptance criteria might be “When the user clicks on the Size drop down list, a list of available sizes will be displayed.”

p� Performance Acceptance criteria should also define and include performance criteria. Performance testing is from the perspective of an individual user. Does the page load quickly? Is the UI responsive? Do I have to wait for ads to load before I can view content? In this new world of cloud and hosted computing, it can be difficult to quantify performance. So performance is usually measured as response time. Expected performance should be clearly spelled out as a range such as “1-2 seconds for a screen to refresh.” And it may make sense to separate out and define performance for specific parts of the solution.

p� Stress Tests Stress tests measure what happens when you are inundated with lots of users, transactions, or queries. What happens when the system is under stress? Acceptance criteria should define acceptable thresholds for stress testing.

6. Review Attributes. Have newly made attributes reviewed by business and technical stakeholders to ensure that they accurately and concisely reflect your feature and the overall solution scope.




Visualization and ElaborationThere are almost endless opportunities for visualizations during this task because the purpose of many visualizations is to provide an easily understandable graphic of a complicated process or concept. Stakeholder collaboration is essential throughout the process of detailing requirements, so using easily understandable visualizations to communicate the business analysts’ needs to the stakeholders and stakeholders’ needs to developers will ensure that concise and relevant detailing of requirements is achieved. For more information on the visualizations included in this section, view the Visualization Methods series on www.RequirementCoach™.com, or revisit Task 5.5 Create Requirement Visualizations for more visualization ideas.

CollaborationWhen providing additional details of your requirement, there are many chances and reasons for collaboration.

Consult With Experts

Collaboration should include consulting experts who are readily available. Consulting subject matter experts is a fantastic way to receive relevant insight. Subject matter experts often provide knowledge that can be invaluable in learning the balance between agility and discipline that you might need in your requirements.

Expert knowledge can come from a variety of sources; the specialist could be an analyst who has extensive experience with the type of data being edited, or a survey sponsor who is familiar with the relationships between the data. Consulting your subject matter experts will also help you see if the details you provided are appropriate, worded correctly, or necessary.

Ask the Right Questions

Asking questions is a key collaboration technique. Unfortunately, many people don’t take the time to ask questions and instead make assumptions or use deductive reasoning, which is a haphazard, poor practice. Often times, when BAs do ask questions, they can be the wrong ones.

To best illustrate this, think back to the last time you were sick. When you went to see your physician, did he or she just walk in, prescription already written, and diagnose you? Hopefully not. Doctors usually sit with their patients and ask question after question while considering the outcomes before arriving at a conclusion. Similarly, you should ask as many questions as possible to discover the best level of detail the requirement demands. This will help when balancing flexibility against discipline in your approach. Questions may be asked in the form of questionnaires, another valuable collaboration technique.




Task Completion ChecklistThe following checklist will determine whether or not your attributes are varied and an acceptable level of elaboration has been taken while detailing the requirement.

✓

When attributes are necessary, are multiple attribute types present?

Have you considered Just in Time as a lean practice?

Are additional details at the right level?

Did you use requirement patterns?

Did the requirement patterns help BAs to improve the quality of requirements?

Did you completely fill in the specialized fields for each requirement pattern?

Do all the requirements that need attributes have them?

Are your attribute types clear?

Have you considered acceptance criteria?

Have you consulted subject matter experts to help provide necessary details?

Are you taking the time to ask the right questions?

Did you use questionnaires and multiple visualization methods?


Organize and Classify Requirements

5.7 Chapter Seven

IntroductionOne task the business analyst may find difficult is organizing and classifying requirements. This is a necessary step, nonetheless, that can be easily accomplished using RequirementPro™. Without proper analysis, documentation, or organization, the business analyst will often create misguided requirement wish lists that do more damage than good during development. Development teams can waste weeks working on features that will probably never roll out; however, waste such as this can be prevented through analysis using tags. Organizing and classifying requirements provides the business analyst with new ways to analyze requirements and split them up in a manner that allows for new perspectives. RequirementPro™ offers an extensive tagging system to assist in the organization, classification, and analysis of requirements.

Tags are short descriptors that can be added to requirements for classification and identification purposes for quickly determining any number of things, such as a requirement’s priority or categorization. Requirements can also be identified through tags to provide an alternate form of requirements analysis. In addition to the tags already offered in RequirementPro™, the business analyst may create organization- or project-specific tags, as well. Tags provide requirements further classification and organization in the areas of priority, business objectives, and customer urgency.



Chapter Seven: Organize and Classify Requirements

Core Concepts

Tagging

In general, tagging is the practice of creating and managing labels (or “tags”) to categorize content using simple keywords. Tagging is done for the purpose of classification, marking ownership, and indicating boundaries or due dates. Key words or phrases are used as tags within RequirementPro™ to ensure that requirements remain as organized and classified as possible. If the business analyst wishes to associate each requirement with multiple labels or categorizations, then tags for these themes can be identified or created and then attached to each of the features to create sub-collections of requirements. In this way, tagging allows the business analyst to manage what would otherwise be unwieldy amounts of information regarding requirements.

Tagging is also immensely useful when combined with RequirementPro™’s search bar. Depending on the type of search being conducted, entering multiple tags into the search bar will bring up either all instances of the tags being searched for (including instances with additional tags not included in your search), or specific instances involving only the tags included in the search.

Requirements Are Analyzed in a Variety of Ways

Tags enable the business analyst to analyze requirements in a variety of ways. For example, the BA can quickly determine when a requirement will be ready for delivery, and then analyze other requirements with the same delivery date at the same time. Similarly, impacted stakeholders, etc. can be identified enmasse. A search of tags could be used to reveal all items that have been tagged as “urgent” and “complex”. The isolation, combination, or search of tags may be used as an alternative requirement analysis technique.




ProcessTagging allows the business analyst to associate requirements with characteristics like importance, value, size, complexity, etc. and then filter and search based on these characteristics. RequirementPro™ comes preloaded with tags that will be extremely useful to your enterprise development effort. RequirementPro™ also allows the BA to define and color-code these tags for organization or project wide use. The following process details how to organize and classify requirements using tags within RequirementPro™.

1. Determine How to Use Tags. Initially, the business analyst must become familiar with the different types of tags. RequirementPro™ comes with the following list of default tags for the Business Analyst to begin working with:

Importance Tags—describe how important the need is.

p� Essential

p� Nice to Have

p� Not Needed

Value Tags—describe how the requirement will help the business.

p� Cost Reduction

p� Revenue Generation

p� Image and Reputation

p� Customer Satisfaction

p� Employee Satisfaction

p� Process Efficiency

Urgency Tags—describe how urgent the requirement is.

p� Urgent

p� Important

p� Can Wait

Complexity—refer to how intricate the requirement will be to build and implement.

p� Simple

p� Moderate

p� Complex




Time-frame—refer to when the requirement should be built/delivered.

p� Iteration 1

p� Iteration 2

p� Iteration 3

p� Release 1

p� Release 2

p� Release 3

Effort—describe how long it will take to produce your requirement.

p� Small

p� Medium

p� Large

Dimension—describe what will be impacted.

p� People

p� Process

p� Technology

Compliance—help prevent governmental compliance issues.

p� Corporate Compliance

p� Risk

p� Audit

p� Internal Control

p� Regulatory

Impact—refer to the organizational change or business process impact.

p� Work Group

p� Business Unit

p� Enterprise

p� Extended Enterprise

Once the business analyst is comfortable with the different types of tags available in RequirementPro™, he or she should plan how requirement tags will be used organization wide and project wide for maximum benefit and organization. The business analyst should talk with development to determine what tags are important to them. Doing this could reveal that development would like specific tags for complexity .




2. Tag Requirements. After becoming familiarized with the pre-loaded tags in RequirementPro™ , the business analyst may begin tagging requirements and adding customized tags to RequirementPro™. Specific project tags can be attached to each requirement record, as it suits the record content. When an authorized user opens a project, a pre-assessed best practices cache of project tags auto-populate the system, usable within the following records:

p� Requirements

p� Needs

p� Scenarios

p� Features

To tag a requirement using the pre-loaded tags, simply navigate to the requirement detail page, scroll to the Manage Tags section, and click Manage Tags as displayed below. Tags can also be added to requirements as they are made.

Scroll down the tag list and identify the tags that fit your Requirement. Click a tag once to highlight it, and attach it to the Requirement; click a highlighted tag again to remove it from the Requirement. When you are finished tagging, click Done to save.




Besides these preloaded tags, the business analyst can add customized tags as they see fit. To add an organization or project specific tag, start by selecting the project setting tab (represented by a gear icon) on the navigation bar. After selecting the Project Setting tab, select the Tag Management tab located on the left side of the page.

On the Tag Management page, you can either create new tags or edit the ones that already exist. To do this, simply select the New button to create a tag, or select an already established tag to edit it. Both actions enable the business analyst to create or alter a name, and select or change a tag’s coloration.




3. Conduct Analysis Using Tags. Because tags serve to organize and classify requirements, tagged requirements can be identified, pulled up using the search bar, and then used for requirements analysis purposes. Depending on the type of search being conducted, selecting multiple tags will bring up either all instances of the tags being searched for (including instances with additional tags not included in your search), or specific instances involving only the tags included in the search. For example, the BA can select the tag “Cost Reduction” and then conduct a risk analysis of the requirements found.

With RequirementPro™, the BA can also select the tags “Complex, “Large,” and “Not Needed” to display all requirements including those tags exactly. The resultant list of requirements could then be analyzed and edited to ensure that “Large” and “Complex” requirements are of more importance than just “Not Needed.” Requirements analysis using tags is helpful for determining if a feature is properly defined, or if a requirement is outside of the project scope.




Sort by Tags

Sort requirements, needs, scenarios, and features by tags easily within the Requirements List. Begin by clicking the ‘Tags’ drop-down button on any Requirements List page. Select two tags, and then choose ‘and’ or ‘or’ from the tag selector menu. The Need List will then generate either all of the Needs containing at least one of the terms you selected, or all of the Needs containing all of the terms you selected, depending upon your ‘and/or’ choice. Finally, click the Search button to begin your search.




Task Completion ChecklistAnswering the following questions will ensure that Task 5.7 Organize and Classify Requirements has been completed in its entirety.

✓

1. Did the business analyst initially determine how tags were to be used organization or project wide?

2. Did the business analyst tag requirements?

3. Did the business analyst create customized tags?

4. Did the business analyst color code all tags?

5. Was requirements analysis achieved through the use of tagging?




IntroductionWithout requirements prioritization, the project team cannot get the most valuable features to customers first. The users may think, “Why would they focus on giving me these features first, I barely use or need them?” Whereas, if requirements are prioritized, the project team can provide a valuable first impression to keep stakeholders engaged and increase the chance of solution adoption within the business.

Establishing each chunk of a solution’s relative importance lets the business analyst sequence construction stages to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization, because developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements. Collaboration and communication are essential for prioritizing requirements.

In this section, you will be able to take sets of requirements and establish rank among them. During this process, a priority is assigned to each functional requirement to indicate how essential it is to a particular system release. If all requirements are viewed as equally important, it might be hard for the project team to respond to schedule overruns, new requirements, or budget issues.

Prioritize Requirements

5.8 Chapter Eight



Chapter Eight: Prioritize Requirements

Core Concepts

Prioritization Eliminates Non-Value Added Requirements

Requirement prioritization is used in project management to determine which requirements are low priorities. For software developers, prioritizing the functional requirements of a software product will indicate that high priority requirements should definitely be included in a certain release. However, requirements prioritization also works the other way around: while high priority requirements are essential, low priority requirements should be reviewed to ensure that they are necessary and value adding.

Prioritizing Features is Easier than Prioritizing Requirements

Even though this task doesn’t focus on prioritizing features, it is important for the business analyst to realize that it is easier to prioritize features than requirements. Features are high-level collections of related requirements, so they will be easier for the business analyst to prioritize on a business level. Requirements, on the other hand, will be more numerous because they make up features and contain more specific, lower levels of detail. If your team appropriately prioritized features in Task 3.6 Define Solution Features prioritizing the requirements within a feature will be significantly easier. Prioritizing in this two-fold method of first prioritizing features and then prioritizing requirements ensures that less important elements are eliminated early on.

Collaboration is Key to Prioritization

Collaborating with stakeholders during requirement prioritization is essential to properly prioritizing and ranking requirements. Without input from business stakeholders, the business analyst has no way of knowing which requirements are highly valued, and which ones would just be nice to have. Collaboration during requirement prioritization is critical to ensure that requirements are viewed from every angle possible, so much so that prioritization cannot be successfully performed without stakeholder collaboration.

Stakeholder input also allows you to see which requirements are needed right away and which can wait. One common problem stakeholders encounter is that they believe all requirements are high priority. It is the business analyst’s responsibility to encourage stakeholders to identify lower-priority requirements as well. To facilitate this process, ask questions similar to the following:

p� What would be the consequence of omitting the requirement?

p� What would the impact be if the requirement were not implemented immediately?

p� Why would a user be unsatisfied if this requirement were deferred to a later iteration?




While it can be difficult leading stakeholders to decide which of his or her requirements are most important, gaining agreement among multiple stakeholders with diverse expectations is even more challenging. People naturally have their own interests at heart and they aren’t always willing to compromise their needs for someone else’s benefit. However, making such priority decisions is one of the stakeholder’s responsibilities in the customer-developer partnership.

Stakeholders prioritize requirements initially from the perspective of how valuable each requirement is to them individually. Collaborating with development is important to understand the technical complexity of requirements as well, because it can influence how the stakeholders view the requirements. Once a developer points out the cost, technical risk, or other trade-offs associated with a specific requirement, though, the stakeholders might decide a requirement isn’t as essential as they thought. The developers might also determine that certain lower priority functions should be implemented early on because of their impact on the product architecture. When setting priorities, stakeholders should be encouraged to balance the business benefit that each function provides against its cost and any implications it has for the product’s future evolution.

Collaborating with stakeholders should take place throughout the entire requirement’s prioritization process.




ProcessEvery organization has to balance project scope against the constraints of schedule, budget, staff resources, and quality. If customers don’t differentiate their requirements by importance and urgency, then the business analyst is forced to make misguided trade-off decisions. Customers may not agree with the project manager’s decisions, so they must indicate which requirements are critical and which can wait. Priorities should be established early on in the project while there are more options available for achieving a successful project outcome and there’s still time to ensure stakeholder satisfaction.

But, how do you get one stakeholder to prioritize his or her requirements, let alone multiple stakeholders? People generally keep their own concerns at heart and are not always willing to come to an agreement if they feel strongly about something. However, as requirements expert Karl Wiegers believes, making such priority decisions is one of the stakeholder’s responsibilities in the customer-developer partnership. Some people believe priorities are unnecessary, but what happens when there are numerous functions and the stakeholders want to implement them all? A project team will run into all kinds of problems thinking every requirement is a top priority. Wiegers points out that even if developers think priorities are a waste of time, it is a good practice to categorize requirements because it ensures a sequential implementation of features based on their importance. In fact, Karl Wiegers has a wealth of requirements knowledge that is recommended by Enfocus Solutions Inc., and some of his ideas for prioritizing requirements have been incorporated with the best practices for requirements prioritization to produce the process detailed on the next page.

Certainly, some requirements are more significant than others. By prioritizing requirements early in your project, those tricky “trade-off” decisions between desired requirements may be made a little earlier on, rather than towards the end of the project. Using RequirementPro™, a stakeholder can easily prioritize requirements. If your team appropriately prioritized the features in Task 3.6 Define Solution Features, this step should be significantly easier to perform. Remember that prioritizing in this two-fold method ensures that lesser important elements are eliminated early on in the project.

When prioritizing a requirement, the business analyst should ask questions such as, “How important is this requirement to the future of the business?” and “How essential is a requirement to a particular feature?” Although each requirement should document something stakeholders really need or something required to conform to an existing requirement, external interface, or standard, in reality, some system capabilities are more essential than others. Stakeholder expectations are usually high and timelines are generally short, so project teams need to ensure the product delivers the most valuable functionality as early as possible to eliminate waste. One of the most important tasks when prioritizing requirements is to determine how each requirement’s functionality will benefit stakeholders, so collaboration is essential throughout the entire requirements prioritization process.




Remember that stakeholder collaboration must be done before, during, and after requirements prioritization for accuracy. Prioritizing requirements involves the following process steps:

1. Use requirements prioritization approaches or MoSCoW analysis to begin splitting requirements into prioritization levels and rank.

2. Enter priority levels into RequirementPro™ and then rank requirements within each priority level.

3. Utilize the voting feature for further prioritization suggestions after a requirement’s priority has been input into RequirementPro™.

1. Use Requirements Prioritization Criteria or MoSCoW Analysis.

Business analysts may initially determine requirement priority by using either requirements prioritization approaches, Moscow analysis, or a combination of the two. RequirementPro™ allows requirements to be defined as either low, medium, or high priority within a feature, and then allows for requirements in each priority level to then be ranked. A description of the priority levels provided in RequirementPro™ include:

p� High: A high priority requirement is a requirement that must be incorporated in the next product release.

p� Medium: Medium priority requirements are requirements that are necessary but can be deferred to a later release if necessary.

p� Low: Low priority requirements are requirements that would be nice to have, but you might realize that could be dropped if you don’t have sufficient time or resources.

Because MoSCow analysis is a practice used to split requirements into categories that can easily be translated and then input into RequirementPro™, MoSCow analysis will be discussed first in this step, and then Requirement Prioritization Criteria will be explained.




MoSCoW Analysis may be used during requirements analysis to help find a shared understanding with stakeholders on the importance placed on each requirement’s delivery. This technique will split requirements into four distinct categories. The basic definitions for these four categories are:

p� Must: Requirements labeled as ‘Must’ are, essentially, requirements you must have. You might think of them as very high priority requirements that must be part of your solution. This is necessary for a solution to be considered a success.

p� Should: Requirements labeled as ‘Should’ are also high-priority requirements. ‘Should’ indicates that these are just as important as the requirements in the ‘Must’ category, but there is a possibility that there are other ways to satisfy these requirements. There is also the possibility that it isn’t feasible given time constraints.

p� Could: Requirements labeled as ‘Could’ are of less importance and might just be nice to have.

p� Won’t: Requirements labeled as ‘Won’t’ should not be implemented. They may, possibly, be included in a later release, though it will most likely be excluded from your solution.

Through the use of MoSCoW analysis, the business analyst might redefine, delete, or add one or more requirements to the feature requirements being prioritized. The BA may also change a requirements list if discussions with stakeholders provide a new understanding or data. It is likely that requirements will be moved up and down a prioritized list as stakeholders discuss and implement MoSCoW. MoSCoW analysis loosely aligns with the priority levels present in RequirementPro™. A requirement considered a ‘Must’ would be entered into RequirementPro™ as a high priority, a requirement considered a ‘Should’ would be entered into RequirementPro™ as a medium priority level, and a requirement considered a ‘Could’ would be entered into RequirementPro™ as a low priority. ‘Won’t’ requirements will not be prioritized and should be descoped from the project. Descoped requirements are not deleted and may be added to the project at a later date or accessed for reuse on other projects.

Using the following requirements prioritization approaches is another option for prioritizing requirements, but doesn’t provide a clear segue for entering prioritizations into RequirementPro™. The business analysts at Enfocus Solutions Inc. recommend using MoSCoW analysis to prioritize requirements as either high, medium, or low level, and then applying the following prioritization approaches to assist in ranking requirements within their prioritization levels.




The requirements prioritization approaches below will work best when combined with MoSCoW analysis, but may be used independently of MoSCoW analysis for requirements prioritization. Requirements prioritization approaches include analyzing and prioritizing requirements based off of the following:

p� Business Value: In the business value approach, prioritize requirements based on cost-benefit analysis of their relative value to the organization. In this approach, the most valuable requirements will be targeted for development first. This is a common way to enhance existing solutions that are already able to meet specified, minimum requirements or deliver the solution incrementally.

p� Business or Technical Risk: Using the business or technical risk approach, you should select requirements that present the highest risk of project failure. The selected requirements should be investigated and then implemented before proceeding; this helps to ensure that, if the project does fail, it fails after only minor expenditures.

p� Implementation Difficulty: When using the implementation difficulty approach, you select requirements that are easiest to implement. Implementation difficulty as an approach is often selected during a pilot of a new development process or tools or when presenting a packaged solution, since it allows your project team to gain familiarity with those things while working on lower-risk requirements.

p� Likelihood of Success: The likelihood of success approach focuses on the requirements that usually produce quick and almost guaranteed successes. This can happen when projects are controversial and progress indicators are necessary to gaining support for your initiative.

p� Regulatory or Policy Compliance: The regulatory or policy compliance approach prioritizes requirements that must be implemented to meet regulatory or policy demands imposed on the organization. This may take precedence over other stakeholder interests.

p� Relationship to Other Requirements: A requirement might not be of high value in and of itself, but rather, may support other high-priority requirements. If this is the case, the requirement may be a candidate for early implementation. In some cases, other requirements or features may have a dependency on the implementation of another requirement and will need to be implemented first, likely as a high priority.

p� Stakeholder Agreement: The stakeholder agreement approach requires the stakeholders to be in unanimous agreement over the requirements that are most useful. This is, more often than not, used with at least one of the other approaches discussed here.

p� Urgency: The urgency approach prioritizes requirements based on time sensitivity.

p� Frequency of Use: The frequency approach prioritizes requirements based on the expected usage frequency.




2. Enter priority levels into RequirementPro™.

Entering the requirements’ priority levels into RequirementPro™ and then ranking those requirements within each priority level is next. When the business analyst first enters a requirement into the application, he or she is required to enter a priority level, as pictured below.

However, by clicking the Edit button on the Requirement Detail tab, a requirement’s priority level can easily be changed.

After adjusting requirement priority levels, it is likely that you will have many requirements in each priority level, so the business analysts at Enfocus Solutions suggest ranking the requirements within each priority level to get the most precise evaluation possible. Requirements that have the statuses of draft, descoped, or bundled cannot be ranked within priority levels. Additionally, only functional requirements may be ranked.







To rank your requirements, navigate to the Requirements tab of the feature you are working with. The Prioritization button will allow the business analyst to choose a prioritization level and then requirements within that prioritization level will appear. From this point, simply drag your requirements up or down to where you believe they hierarchically belong. Whenever the priority of a requirement changes, that change should be reflected in RequirementPro™ to ensure all information is kept up-to-date.

3. Utilize Voting.

According to the Business Analysis Body of Knowledge (BABOK), voting is technique that is useful for prioritizing requirements. Voting is fairly self-explanatory—through the voting feature in RequirementPro™, stakeholders and project contributors vote to help prioritize requirements by clicking either a thumbs up or thumbs down icon attached to a requirement. Voting is meant to be extremely straightforward, and votes may be viewed across sets of proposed requirements. This way, everyone has a voice in requirements prioritization. A variety of methods may be used to vote on requirements during prioritization in addition to the option included in RequirementPro™; just try to be consistent. The business analyst will have to decide the minimum amount of votes necessary to show support for a requirement. Alternatively, a large amount of thumbs down, or votes against a requirement, should signal that a requirement needs to be reevaluated to find what stakeholders have found lacking or unacceptable.




Task Completion Checklist The following task completion checklist ensures that the business analyst has successfully completed this task in its entirety.

✓

1. If you used the Requirements Prioritization Approaches for ranking, were requirements prioritized and ranked according to the following criteria?

p� Business Value

p� Business or Technical Risk

p� Implementation Difficulty

p� Likelihood of Success

p� Regulatory or Policy Compliance

p� Relationship to Other Requirements

p� Stakeholder Agreement

p� Urgency?

2. Did stakeholders to ensure that everyone’s voice was heard through the use voting? If so, did the voting results reveal any requirements as a higher or lower priority than originally believed?

3. Do all requirements in the project now reveal an appropriate priority level reflective of requirement prioritization stakeholder collaboration and processes?

4. Did you rank your requirements?

5. Do you think each requirement’s prioritization is representative to the value it should provide?




Verify Requirements

5.9 Chapter Nine

IntroductionRequirements are verified to ensure they are acceptable to base future work on. Using a tool such as Enfocus Requirements Suite™ will shorten the cycle time for the review and verification of requirements because business analysts and stakeholders alike are easily able to take part in a final requirements review. Requirements are verified to make sure that they are ready for user validation and to ensure that they are complete. The concept of complete, however, is tricky because requirements containing too much detail can be a hindrance, but requirements containing too little detail are inoperable too. Catching incomplete requirements early can save time and produce better quality requirements, ultimately leading to a satisfied stakeholder community.

The business analyst needs to know that he/she is working with an adequate set of requirements. It’s important to know that the product you build has a high chance of satisfying customer needs and will let people get their jobs done in a way they find acceptable and maybe even enjoyable. But without taking the time to verify the requirements, the risk of missing the mark goes up.



Chapter Nine: Verify Requirements

Core Concepts

INVESTed Requirements

As we’ve stated previously in this guide, requirements need to be:

Independent: Can it be built independently? The requirement must be defined, analyzed, built, and managed separately from all other features.

Negotiable: Are the details of how the requirement is to be implemented negotiable? The requirement is not an explicit contract. Ensure tradeoffs can be made if necessary.

Valuable: Will it deliver business value and meet an organizational need? The requirement must be valuable to stakeholders.

Estimable: Can the project team determine a good approximation of effort? It should be possible to determine the relative size of each requirement to ensure costs can be estimated and work activities can be planned.

Sized Right: Is it appropriately sized to be feasibly built? All solution requirements should have the same level of detail. This element of the acronym relates more to the attributes and other details that will be fleshed out in Task 5.6 Elaborate with Additional Details.

Testable: Can you clearly identify a test to ensure the requirement has been delivered? The project team must be able to verify whether the feature was successfully delivered.

Discovering Poor Requirements Early Saves Money

Discovering poor requirements early helps to prevent rework and confusion. Verifying your requirements as you develop them significantly improves requirement quality. An unverifiable requirement is a bad or unnecessary requirement; if you can’t verify it, then you can’t design it or build it. For example, take the requirement “The product must be reliable.” What is reliable? If you can’t define what reliable is, how will designers know what reliable is? If you can’t verify this requirement you may not be able to convince your customer that your product is reliable.

Also, many software developers have experienced the frustration of being asked to implement requirements that were ambiguous or incomplete. If they can’t get the information they need, the developers have to make their own interpretations, which aren’t always correct. Substantial effort is needed to fix requirement errors discovered after those requirements have already been implemented. Any measures you can take to detect errors or missing information in the requirements specifications will save you considerable time and money.




ProcessVerification is the process of confirming that the designed and built product fully addresses the requirements and consists of performing various inspections, tests, and analyses throughout the product lifecycle to ensure that the design or finished product fully addresses the requirements. Verification can be thought of as a “quality check.”

RequirementPro™ allows stakeholders and the project team to work together to verify requirements. Throughout the verification process, stakeholders are kept informed of changes to requirements and can easily work together to elaborate on requirements, ensuring that the requirements are understood and achievable. Developers and stakeholders have the ability to post questions and comments about requirements, a feature which encourages close collaboration. Task 5.5 Create Requirement Visualizations, and Task 5.6 Elaborate with Additional Details should be completed before requirements verification to deliver complete requirements including visualization methods, such as process flows, UML diagrams, mind maps, videos, etc., and so that all of the applicable attachments are available for the community to view. Keeping everyone involved in prioritizing and validating requirements is an action that contributes to a successful solution.

1. The business analyst, with the help of the project team and related stakeholders, will need to ensure that each requirement is of high quality and portrays, at the minimum, the following characteristics defined in BABOK:

p� Cohesive: Are all of the requirements in the feature related to only one thing, whether that thing may be a business rule, process, etc.? Requirements within a feature should support the feature’s purpose and the project’s scope.

p� Complete: Does each requirement contain or reference sufficient detail, examples, pictures, and other explanatory material? Does it cover all attributes? Every requirement should contain a complete description that covers all attributes and includes enough narrative and all necessary attachments for the developer to design and implement that bit of functionality. Each requirement must fully describe the functionality to be delivered. Completeness should be measured thoroughly as to make sure that data flow diagrams have properly placed arrows.

p� Consistent: Individual requirements should follow a loose consistency. Each requirement should contain approximately the same amount of detail and attachments, and requirements should not contradict each other. Requirements begin to contradict each other whenever one overpowers another, or when ever one requirement describes another using different wording.

p� Modifiable: When changes are necessary, will they be made easily, completely, and consistently? The requirement needs to establish a sound foundation for development that accepts the inevitability of change. Requirements are modifiable if they are structured and styled so that any necessary changes to any requirement can easily be made.




p� Feasible: Is it feasible to perform with existing constraints, such as time, money, and available resources? Requirements must realistically achievable and cost-effective. A good way to identify and avoid infeasible requirements is having a developer collaborate with a requirements analyst.

p� Unambiguous: Did you make sure to avoid uncertain terms, jargon, and wordiness so that the requirement is clear and easily understood? One of the most common and detrimental mistakes in projects is the misinterpretation of requirements. If there are multiple readers of a requirement (which there usually are), they should all arrive at the same understanding. Besides the use of unambiguous language, ensure there is no jargon in the requirement that could be confusing. A requirement needs to be concise and understandable so that it clearly communicates a specific message to development—developers must be able to build what the stakeholders want.

p� Correct: If requirements contain defective information, then the solution will be defective as well.

The INVEST method explained on page 134 should also be used in conjunction with BABOK characteristics to guarantee requirement quality.

2. Verification activities should also be completed periodically to ensure that requirements adhere to the characteristics mentioned above. According to BABOK, typical verification activities include:

p� Checking for Completeness. For example, diagrams will have all components and data labeled and will include small indicators such as appropriately placed arrows or symbols.

p� Comparing Requirements. Each requirement is compared to all other requirements for consistency’s sake. Each requirement shall be checked to make sure that it contains roughly the same amount of information, attachments, and visuals as other requirements. Also, language should be checked for consistent use of terminology.

p� Identifying Variations. Ensure that any variations in processes are identified and documented.

p� Identifying Triggers and Outcomes. Make sure that for every variation, triggers and outcomes have been determined.

p� Managing Terminology. Terminology used in requirements should be easy for stakeholders to understand and comply with organizational terminology and word usage.

p� Adding Examples. Examples should be added to requirements as needed for clarification support.




CollaborationCollaboration during requirements verification will prove valuable. Collaboration between the business analyst team and project team can be used to verify each other’s requirements. This fosters teamwork and quickly establishes a consistent standard for how to write the requirements. The business analyst can hold a requirements review session to review each team’s requirements together.

The business analyst may also collaborate with the quality assurance team, especially when trying to verify the quality of ‘Testable.’ Quality analysis teams are a great resource to use for collaboration and will happily tell you if a requirement is untestable. This will save the quality assurance team time later on and prevent the business analyst from having to do rework.




Task Completion ChecklistTo ensure that each requirement displays the above-mentioned BABOK characteristics, checklists may be employed. The following checklist will include quality elements and ensure that issues and concerns to the project are identified. Checklists may be used to guarantee that necessary requirements are included in the initial phases of implementation, or to ensure that organizational processes are being followed, as well.

✓

Are the requirements written in a language and vocabulary that the stakeholders understand? Do the stakeholders concur?

Have the requirements been mapped to stakeholder needs? Are needs that were not addressed by requirements clearly identified with a reason and explanation?

Have the requirements been reviewed by internal audit for internal control issues?

Have the requirements been reviewed for compliance and regulatory issues?

Do the stakeholders know of major omissions that have not been addressed?

Are the requirements written in a language and vocabulary that the developers understand? Do the developers concur?

Are the requirements specified clearly enough to be turned over to the development teams for implementation?

Does the development team consider the requirements realistic given the project constraints?

Are there areas where the developers need more detail or supporting documents to understand the requirements?

Are the requirements complete? Do they cover all of the new features needed in this release?

Are all requirementsactual requirements, not design or implementation solutions?

Are there any conflicts between some of the requirements?

Are requirements specified in a concise manner that avoids the likelihood of multiple interpretations? Are there duplicate requirements?

Are the requirements supported with graphics and other visualization methods?

Is each requirement relevant to the problem and its solution?




Task Completion Checklist Cont.

✓

Are the non-requirements clearly identified? In other words, are proposed requirements were dropped during the review process and are not part of this release identified?

Are functional requirements separated from non-functional requirements? Are all of the requirements prioritized?

Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?

Have all the requirements regarding application programming interfaces been defined?

Have all the requirements regarding the external hardware and software, and minimum system requirements been defined?

Are there any requirements that specify how errors and/or anticipated failure paths should be handled?

Have all the issues regarding internationalization been properly addressed?

Have all the non-functional requirements been properly specified?

Are all the tasks to be performed by the system/software specified?

Does each task specify the data/information content used in the task and the data/information content resulting from the task?

Are the physical security requirements specified?

Are the operational security requirements specified?

Is the reliability of the system/software specified, including the consequences of failure, vital information protected from failure, error detection, and recovery?

Are internal interfaces, such as software and hardware, defined?

Are external interfaces, such as users (e.g., people), software, and hardware defined?


