Karl and Joy have updated one of the most important works on software requirements, taking what was good and improving upon it. Doreen Evans, managing director of the requirements and business analysis practice for Robbins Gioia Inc.
Links in the requirements chain 491
Tools for requirements engineering 503
IMPLEMENTING REQUIREMENTS ENGINEERING
Improving your requirements processes 517
Software requirements and risk management 537
Introduction
A new chapter on handling requirements for agile projects has been added to this third edition, as well as sections in many other chapters that describe how to apply and adapt the practices in those chapters to an agile development environment. We've learned that these practices are applicable to almost any project: small and large projects, new development and enhancements, with local and distributed teams, and using traditional and agile development methods.
Benefits this book provides
This book provides dozens of tools to facilitate that communication and help software practitioners, managers, marketers, and customers implement effective requirements engineering methods. Think of these practices as tools to help you make sure you're having effective conversations with the right people on your projects.
Who should read this book
Looking ahead
Other chapters in Part II address how to find appropriate customer representatives, elicit requirements from them, and document user requirements, business rules, functional requirements, data requirements, and nonfunctional requirements. The self-assessment in Appendix A can help you select areas ripe for improvement.
Case studies
The business analyst role (a role that goes by many other names) is the subject of Chapter 4. The principles and practices of requirements management are the subject of Part IV, with an emphasis on techniques for handling changing requirements.
From principles to practice
Errata & book support
We want to hear from you
Stay in touch
Acknowledgments
She was a lot of fun to work with, and she added a lot of value to the book. She would especially like to thank two colleagues and friends: Anthony Chen, whose support for her writing this book was extremely important; and Rob Sparks, for his continued encouragement in such endeavors.
The essential software requirement
Many problems in the software world arise from deficiencies in the way people learn about, document, agree on, and modify product requirements. Nowhere more than in the requirements are the interests of all the stakeholders in a project crossed.
Taking your requirements pulse
Software requirements defined
Some interpretations of ”requirement”
The pure dictionary “requirement”
Levels and types of requirements
Business requirements describe why the organization is implementing the system—the business benefits the organization hopes to achieve. Functional requirements are often written in the form of traditional "must" statements: "The passenger must be able to print boarding passes for all flight segments for which he has checked in" or "If the passenger's profile does not show a seat preference, the reservation system assigns a seat.”
If they’re nonfunctional, then what are they?
Therefore, you can trace the genesis of some functional requirements to a particular business rule. A feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.
Working with the three levels
When someone suggests a new feature, user requirement, or bit of functionality, the analyst should ask, "Is it in scope?" If the answer is "yes", the requirement belongs in the specification. The third possible answer is "no, but it supports the business goals, so it should be." In that case, whoever controls the project scope—the project sponsor, project manager, or product owner—must decide whether the current project or iteration's scope should be increased to accommodate the new requirement.
Product vs. project requirements
Especially for business applications, people sometimes refer to a "solution" that includes both product requirements (which are primarily the responsibility of the business analyst) and project requirements (which are primarily the responsibility of the project manager). They may use the term "solution scope" to refer to "everything that needs to be done to successfully complete the project." In this book, however, we are focusing on product requirements, whether your end product is a commercial software product, a hardware device with embedded software, a corporate information system, contracted government software, or anything else.
Requirements development and management
Requirements development
Elicitation
Usage-centric or product-centric?
Analysis
Specification
Validation
Requirements management
The purpose of requirements management is not to stifle change or make it difficult. It is anticipating and accommodating the very real changes that you can always expect to minimize their disruptive impact on the project.
Every project has requirements
Without knowing the requirements, you cannot tell when the project is finished, determine whether it has met its goals, or make trade-off decisions when scope adjustments are needed. Instead of spending time on requirements, people should balk at the money wasted when the project doesn't pay enough attention to requirements.
When bad requirements happen to good people
In those cases, you can take an iterative or incremental approach, implementing one part of the requirements at a time and obtaining feedback from customers before moving on to the next cycle. However, this is not an excuse to write code before considering the requirements for the next increase.
Insufficient user involvement
Shortcomings in requirements practice pose many risks to project success, where success means delivering a product that meets the user's functional and quality expectations, at the agreed cost and schedule. Chapter 32, “Software Requirements and Risk Management,” describes how to manage such risks to prevent them from derailing your project.
Inaccurate planning
Creeping user requirements
Ambiguous requirements
Gold plating
Overlooked stakeholders
Benefits from a high-quality requirements process
Next steps
Requirements from the customer’s perspective
Gerhard mentioned some business objectives, benefits that he expects Contoso to reap using the new chemical tracking system. However, Gerhard cannot fully describe the user requirements because he is not the intended user of the system.
Deliverable: Rejected
Part of the requirements problem stems from confusion about the different levels of requirements described in Chapter 1, “Essential Software Requirements”: business, user, and functional. Chapter 6, “Finding the Voice of the User,” describes the different types of customers and users and ways to involve appropriate user representatives in eliciting requirements.
The expectation gap
As the small progressively descending gray triangles in Figure 2-1 illustrate, a series of such touchpoints will lead to a much smaller expectations gap at the end of the project and a solution that is much closer to the actual needs of the customer. That's why one of the guiding principles of agile development is to have constant conversations between developers and customers.
Who is the customer?
The best way to minimize the waiting gap is to arrange frequent touchpoints with appropriate customer representatives. Customers like Gerhard provide the business requirements, which create the guiding framework for the project and the business rationale for launching it.
The case of the missing stakeholder
The customer-development partnership
The Requirement Bill of Rights for Software Customers in Table 2-1 lists ten expectations that customers can legitimately have regarding their interactions with BAs and developers during the project's requirements engineering activities. The word “you” in the rights and responsibilities refers to a customer for a software development project.
Requirements Bill of Rights for Software Customers
The Pitfall Don't assume that project participants instinctively know how to collaborate in requirements development. It's a good idea to write down how you decide to approach and manage requirements issues in the project.
Right #1: To expect BAs to speak your language
These rights and responsibilities apply to actual customers when the software is developed for internal company use, under contract, or for a known group of larger customers. In mass market product development, rights and responsibilities are more about customer surrogates, such as the product manager.
Right #2: To expect BAs to learn about your business and your objectives
This understanding can reduce friction later, when one party expects something the other is unwilling or unable to provide.
Right #3: To expect BAs to record requirements in an appropriate form
As part of project planning, key customer and development stakeholders should review and negotiate these two lists to reach a meeting of the minds. Your review of these specifications and other requirements representations, such as visual analysis models, helps ensure that they accurately represent your needs.
Right #4: To receive explanations of requirements practices and deliverables
Right #5: To change your requirements
Right #6: To expect an environment of mutual respect
Right #7: To hear ideas and alternatives for your requirements and for their solution
Right #8: To describe characteristics that will make the product easy to use
Right #9: To hear about ways to adjust requirements to accelerate development through reuse
Right #10: To receive a system that meets your functional needs and quality expectations
Requirements Bill of Responsibilities for Software Customers
Responsibility #1: To educate BAs and developers about your business
Responsibility #2: To dedicate the time that it takes to provide and clarify requirements
Responsibility #3: To be specific and precise when providing input about requirements
Responsibility #4: To make timely decisions about requirements when asked
Responsibility #5: To respect a developer’s assessment of the cost and feasibility of requirements
Responsibility #6: To set realistic requirement priorities in collaboration with developers
Responsibility #7: To review requirements and evaluate prototypes
Responsibility #8: To establish acceptance criteria
Responsibility #9: To promptly communicate changes to the requirements
Responsibility #10: To respect the requirements development process
Creating a culture that respects requirements
Such rework is hidden in the daily activities of the project participants, so they do not consider it a serious inefficiency. Developers are stakeholders in the project, but sometimes their input is not requested and they become the 'victims' of the demands imposed on them.
Identifying decision makers
Reaching agreement on requirements
Everyone involved in the request approval process should know exactly what opting out means or problems could arise. Equally problematic is a development manager who sees opt-out as a way to freeze requests.
The requirements baseline
Many organizations use the act of "signing off" (why not "signing off"?) on the requirements as the mark of stakeholder approval. After the decision makers have defined a baseline, the BA must place the requirements under change control.
What if you don’t reach agreement?
Development management has confidence because the development team has a business partner who will keep the project focused on achieving its goals and will work with development to balance schedule, cost, functionality, and quality. Business analysts and project managers are confident that they can manage changes to the project in a way that will keep chaos to a minimum.
Agreeing on requirements on agile projects
Which items from the Charter of Rights and the Charter of Responsibilities do these parties currently accept and implement. If necessary, amend the Bill of Rights and Bill of Responsibilities so that all parties agree on how they will work together.
Good practices for requirements engineering
Please note that this chapter is titled “Good Practices for Requirements Development” and not “Best Practices.” It is doubtful whether all these practices will ever be systematically evaluated for this purpose. Nevertheless, many other practitioners have found these techniques effective (Sommerville and Sawyer 1997; Hofmann and Lehner 2001; Gottesdiener 2005; IIBA 2009).
A requirements development process framework
Due to the diversity of software development projects and organizational cultures, there is no single, formal approach to requirements development. But even if you plan a traditional "requirements phase" at the start of the project, which then leads into design, you can expect to have to do some additional requirements work throughout the project.
Good practices: Requirements elicitation
Distribute Questionnaires Questionnaires are a way of surveying large groups of users to find out what they need. If the questions are well written, questionnaires can help you quickly determine analytical information about needs.
Good practices: Requirements analysis
Analyze interfaces between your system and the outside world All software systems have connections to other parts of the world through external interfaces. Assigning Requirements to Subsystems The requirements for a complex product containing multiple subsystems must be distributed among the various software, hardware, and human subsystems and components.
Good practices: Requirements specification
The convention must be robust enough to withstand additions, deletions and changes made to the requirements over time. Document your business rules separately from a project's requirements because they typically have an existence outside of a specific project's scope.
Good practices: Requirements validation
Simulate Requirements Commercial tools are available that allow a project team to simulate a proposed system either in situ or to augment written requirements specifications. Users can interact with the simulated system to validate requirements and make design choices, bringing the requirements to life before jumping into concrete code.
Good practices: Requirements management
A requirements traceability matrix can also link functional requirements to the higher-level requirements from which they are derived and to other related requirements. Such tools help you implement and automate many of the other requirements management practices described in this section.
Good practices: Knowledge
Educate developers about the application domain To help developers understand the basics of the application domain, hold a workshop on the customer's business activities, terminology, and objectives for the product being created. You can also match each developer with a "user buddy" for the life of the project to translate jargon and explain business concepts.
Good practices: Project management
Because so many decisions involve requirements issues, it is essential for the project team to identify and empower its requirements decision makers, preferably before they face their first major decision. Identify and document risks related to requirements as part of the project's risk management activities.
Getting started with new practices
Monitor the impact your requirements activities have on the project so you can assess the return on your requirements investment. Incorporate the adoption of new requirements techniques into your organization's software process improvement activities, relying on change leadership to facilitate testing, deployment, and adoption of better practices.
The business analyst
The business analyst role
The BA can help represent the users and understand their needs while performing the additional BA activities described later in the chapter. Using highly experienced analysts can reduce the total project effort by a third compared to similar projects with inexperienced analysts.
The business analyst’s tasks
Using standard templates accelerates requirements development by reminding BAs of topics to discuss with user representatives. Validation of the BA's lead requirements must ensure that the requirements statements have the desired characteristics discussed in Chapter 11, “Writing Great Requirements,” and that the requirements-based solution will meet the needs of the stakeholders.
Essential analyst skills
A BA must also be able to summarize and present information at the level of detail that the target group needs. Interpersonal Skills Analysts must be able to get people with competing interests to work together as a team.
Practicing what you teach
BA will need to know when to select specific models based on how they add value. A BA should be easy to communicate with and be clear and consistent when communicating with team members.
Essential analyst knowledge
The making of a business analyst
The former user
Users who become BAs need to learn more about the technical side of software development so that they can present information in the most appropriate forms for their multiple audiences. Some former users think they understand what is needed better than current users, so they do not solicit or respect input from those who will actually use the new system.
From medical technologist to business analyst
The downside is that former users who are now graduate professionals may know little about software engineering or how to communicate with technical people. Recent users may be stuck in the current way of working in the here and now, so that they do not see the possibility of improving business processes with the help of a new information system.
The former developer or tester
They will need to familiarize themselves with current requirements engineering best practices. Developers will benefit from training and mentoring in the various soft skills mastered by top analysts, as described earlier in this chapter.
The former (or concurrent) project manager
The subject matter expert
The rookie
The analyst role on agile projects
Help verify that customer needs are accurately represented in the product backlog and facilitate backlog prioritization. However, the person performing the Product Owner role may not have all the business analysis skills or time to perform all the related activities.
Creating a collaborative team
The point is that regardless of the project's development approach, the tasks associated with the BA role still need to be accomplished. Work with the rest of the team to determine the impact of changes on iteration content and release plans.
Establishing the business requirements
Defining business requirements
Identifying desired business benefits
Product vision and project scope
Important The product vision ensures that we all know where we want to end up. Project scope ensures that we are all talking about the same thing for an immediate project or iteration.
Make sure the vision solves the problem
The project scope identifies which portion of the ultimate product vision the current project or development iteration will address. The scope statement draws the line between what is in and what is out for this project.
Interlocking scopes
Conflicting business requirements
Project decision makers must resolve these conflicts before the analyst can detail the kiosk requirements. Project decision makers should not expect the program team to resolve conflicts between different stakeholders.
Vision and scope document
The vision and scope document only defines the scope at a high level; the scope details are represented by each release baseline that defines the team. Each iteration, release, or enhancement project for an evolving product can include its own scope statement in that project's requirements documentation, rather than creating a separate vision and scope document.
Template tactics
Business requirements
- Background
- Business opportunity
- Business objectives
- Success metrics
- Vision statement
A business objectives model shows a hierarchy of related business problems and measurable business objectives (Beatty and Chen 2012). In other cases, achieving business objectives may depend on projects that go beyond your current ones.
Crafting the product vision
Business risks
Business risks are not the same as project risks, which often include concerns about resource availability and technology factors.
Business assumptions and dependencies
Scope and limitations
Scope can be represented in numerous ways (see “Scope Representation Techniques” later in this chapter). At the highest level, scope is defined when the customer decides which business objectives to target.
Blue-sky requirements
- Major features
- Scope of initial release
- Scope of subsequent releases
- Limitations and exclusions
- Business context
- Stakeholder profiles
- Project priorities
- Deployment considerations
At each level, the scope must stay within the boundaries of the level above it. In this section, explicitly state: "The new system will not provide mobile platform support."
Scope representation techniques
Important Not all five dimensions can be constraints, nor can they all be drivers. Provide a summary of the information and activities required to ensure effective implementation of the solution in the operational environment.
Context diagram
Record any information that will be needed by people who will prepare training or modify business processes in conjunction with the implementation of the new solution. However, those processes take place outside the scope of the Chemical Detection System, as part of the operations of the purchasing and receiving departments.
Ecosystem map
Feature tree
Event list
Keeping the scope in focus
Using business objectives to make scoping decisions
Assessing the impact of scope changes
Vision and scope on agile projects
Scope management and timeboxed development
Many agile projects perform a preliminary design iteration (iteration zero) to define the overarching product vision and other business requirements for the project. Business requirements must be defined for all software programs, regardless of the development approach.
Using business objectives to determine completion
Or simply create a model of business goals and have the rest of the team review it. This can reveal that your team does not have a shared understanding of the goals or scope of the project.
Finding the voice of the user
If developers build exactly what customers ask for first, they will probably have to build it again because customers often don't know what they really need. If you don't invest the time to achieve this shared understanding—this shared vision of the target product—some results are rework, missed deadlines, cost overruns, and customer dissatisfaction.
User classes
Additionally, BAs may not be talking to the right people or asking the right questions. The features users present as their "wants" are not necessarily the same functionality they need to perform their tasks with the new product.
Classifying users
A better way to identify user classes is to think about the tasks that different users will perform with the system. Disadvantaged user classes are groups that are not supposed to use the product for legal, safety or security reasons (Gause and Lawrence 1999).
Identifying your user classes
Any chemist will use the system several times a day, primarily to request chemicals and track chemical containers to and from the lab. They will deliver containers from three warehouses, request new chemicals from vendors, and track all container movements in and out of warehouses.
User personas
By defining enterprise-level user classes, you can reuse these user class descriptions in future projects. If you do include the user class descriptions in the project's SRS, you can incorporate entries from the Reusable User Class Catalog by reference and simply write descriptions of new groups specific to that application.
Connecting with user representatives
As in the children's game "Telephone", the intermediate layers between the user and the developer increase the possibility of miscommunication and transmission delays. Recognize the risks you take by using marketing staff, product managers, subject matter experts or others as surrogates for the actual voice of the user.
The product champion
Product advocates collect requirements from other members of the user classes they represent and reconcile inconsistencies. For example, product advocates can drive adoption of an application by the user community, which can be a success metric that managers will value.
External product champions
The product master approach works best if each master is fully empowered to make binding decisions on behalf of the user class he represents. These people provided valuable domain expertise as well as insight into the client organization's policies.
Product champion expectations
As another example, my longtime family doctor, Art, left his medical practice to become the voice of a physician for a medical software company. Regardless, if people no longer function in a role, they've simply forgotten the complexity of their day-to-day work.
Multiple product champions
No backup team was needed if the user class was small enough or cohesive enough that one individual could truly represent the needs of the group.1.
The voiceless user class
Selling the product champion idea
However, he willingly made the necessary decisions when agreement was not reached so that the project could continue. Product advocates are one way to get that all-important customer input in a timely manner, not at the end of a project when customers are frustrated and developers are tired.
Product champion traps to avoid
Every organization has horror stories of new systems that failed to meet user needs or failed to meet unstated usability or performance expectations. You can't afford to rebuild or scrap systems that don't fit because no one understood the requirements.
User representation on agile projects
If the product owner functions in the role of a business analyst, rather than as a stakeholder representative himself, he can set up a structure with one or more product champions to see that the most appropriate sources provide input. Alternatively, the product owner may work with one or more business analysts, who then work with stakeholders to understand their requirements.
On-sight” customer
Resolving conflicting requirements
Individual users are set by the product champion or product owner User classes The preferred user class takes precedence. Users and user managers The product owner or product champion for the class of users decides Development and customers Customers take precedence, but in line with business objectives Development and marketing Marketing takes precedence.
Requirements elicitation
The result of requirements development is a shared understanding of the needs held by the various project stakeholders. However, before we go through this process, let's review some of the requirements elicitation techniques that you may find useful.
Requirements elicitation techniques
Interviews
Prepare questions and straw man models ahead of time Prepare for interviews by drafting any material you can in advance, such as a list of questions to guide the conversation. When users really can't articulate what they need, perhaps you can watch them work and suggest ways to automate parts of the work (see the "Observations" section later in this chapter).
Workshops
Complete all the team roles A facilitator must make sure that the following tasks are covered by people in the workshop: note taking, time keeping, scope management, ground rule management, and making sure that everyone is heard. Plan an agenda Every workshop needs a clear plan, as discussed in the "Preparation for elicitation".
Too many cooks
Keep the team small, but include the right stakeholders. Small groups can work much faster than larger teams. Knowledge, experience and decision-making authority are qualifications for participation in elicitation workshops.
Focus groups
Evocation workshops with more than five or six active participants can become bogged down in side trips, simultaneous conversations, and bickering. Workshop participants could include the product master and other user representatives, perhaps a subject matter expert, a BA, a developer and a tester.
When conflicts erupt
Observations
If you use observations in agile projects, have the user demonstrate only the specific tasks relevant to the next iteration. The BA must abstract and generalize beyond the observed user activities to ensure that the captured requirements apply to the user class as a whole, not just that individual.
Watch me bake a cake
By observing a user's workflow in the task environment, the BA can validate information from other sources, identify new topics for interviews, see problems with the current system, and identify ways the new system can better support the workflow.
Questionnaires
System interface analysis
Through system interface analysis, you may learn that multiple systems pass orders to the order management system, which does the validation, so you don't have to build this feature.
User interface analysis
Document analysis
Planning elicitation on your project
Select the row or rows that represent features of your project and read on the right to see which elicitation techniques are most likely to be useful (marked with an X). For example, if you are developing a new application, you are likely to achieve the best results with a combination of stakeholder interviews, workshops, and system interface analysis.
Preparing for elicitation
Align the scope of the session with the overall project scope defined in the business requirements to keep the conversation on topic. Learn about the stakeholders Identify the relevant stakeholders for the session (see Chapter 6, . "Finding the Voice of the User").
Performing elicitation activities
Document the source of each request so you can get further clarification if needed and trace development activities back to the specific customer origin. Come up with a shorthand note to capture a question that comes to mind while someone is speaking, so you can quickly come back to it when you have an opportunity.
Stakeholders on the move
If there are existing objects to view (such as straw man models, existing requirements, or existing systems), project them onto the wall. If several participants are in the same room, use video conferencing tools to show remote participants what's on the walls and whiteboards.
Following up after elicitation
If it is culturally appropriate, use toys to stimulate participants' minds or give them something to do with their hands.
Organizing and sharing the notes
Documenting open issues
Classifying customer input
Repeatedly asking “why” the user needs it to function this way is likely to reveal the true need (Wiegers 2006). If the user replies, "That just seemed like a good way to do it," then the real requirement is something like, "The system must allow the user to specify the state in which to send the packet." But maybe the user says, “We do the same thing in several other places, and I want it to be consistent.
How do you know when you’re done?
The phone must allow the user to swipe with a finger to navigate between screens.”. Also, the dropdown prevents the user from entering invalid data." These are legitimate reasons for specifying a specific solution.
Some cautions about elicitation
Proposed new features, user requirements, or functional requirements are all considered out of scope. If your project requires extensive research, use an incremental development approach to explore the requirements in small, low-risk chunks.
Assumed and implied requirements
No assumed requirements
Finding missing requirements
You will likely never discover all the requirements for your product, but almost any software team can do a better job of eliciting requirements by applying the practices described in this chapter. Identify the prompting techniques that you think would work best and decide how you will implement them next time.
Understanding user requirements
The purpose of this approach is to describe the tasks that users will be required to perform with the system, or the user-system interactions that will produce a valuable result for some stakeholder. This understanding guides the BA to derive the necessary functionality that must be implemented to enable these usage scenarios.
Use cases and user stories
The use case should not be included in the design specifications, only the user's mental image of the interaction. The remainder of this chapter will focus on the use case technique, noting similarities and contrasts with the user story approach where appropriate.
The use case approach
Use cases provide project participants with a structure and context that a collection of user stories lacks. But user stories don't replicate that structure and rigor, so it's easier for the team to miss some acceptance tests.
Users and actors
Use cases and usage scenarios
One or more postconditions that describe the state of the system after the use case has completed successfully. A numbered list of steps indicating the sequence of interactions between the actor and the system - a dialogue - leading from the preconditions to the postconditions.
Use case labeling convention
Preconditions and postconditions
Normal flows, alternative flows, and exceptions
Some error conditions can affect multiple use cases or multiple steps in the normal flow of a use case. Some of the steps in an alternate flow will be the same as in the normal flow, but some unique actions are needed to accomplish the alternate path.
Dressing the use cases
Rather than being dogmatic about how much detail to include in a use case, remember your goal: to understand the user's goals well enough to allow developers to proceed with low risk of having to rework.
Extend and include
Trap Don't have long-winded debates with your colleagues about when, how, and whether to expand and include relationships. An author of a book on use cases told me that extend and include are best discussed with friends over beer.
Aligning preconditions and postconditions
Use cases and business rules
If a passenger executes a use case for selecting a new seat on the airline's website, the relevant business rules would change the passenger's airline ticket if he were to select one of those seats. When defining a use case, record the identifiers of all known business rules that affect the use case and indicate which part of the use case is affected by each rule.
Identifying use cases
As the group explored the remaining use cases in scope in the workshops, they found that some of them were related scenarios that could be consolidated into a single, more general use case. Some users suggested use cases that were not phrased as tasks, such as "Material Safety Data Sheet." A use case's name should indicate a goal the user wants to achieve, so you should start with a verb.
Exploring use cases
Sometimes a proposed use case was just a single step the actor would perform as part of the process, such as "Scan barcode". The BA needs to learn what goal the user has in mind that involves scanning a barcode. The resulting sequence of actor actions and system responses became the normal flow for the use case.
Staying in bounds
When writing the steps in the use case flow, avoid language that refers to specific user interface interactions. Also note any information that may not be visible to the users, such as the need for one system to communicate with another behind the scenes to complete the use case.
Validating use cases
Use cases often involve additional information or requirements that do not fit within any of the template sections. The CTS team created several representations of the requirements they identified: a list of functional requirements, a set of corresponding tests and analysis models, all based on use cases.
Use cases and functional requirements
Many functional requirements fall directly from the dialogue steps between the actor and the system. Some are obvious, such as “The system will assign a unique sequence number to each request.”
Use cases only
To reduce this uncertainty, consider a BA explicitly specifying the functional requirements needed to implement each use case (Arlow 1998). The chemical tracking system used the use cases primarily as a tool to reveal the necessary functional requirements.
Functional requirements only
Use cases and tests
Use case traps to avoid
Incorporating data definitions into the use cases Use case explorations naturally stimulate data discussions, considering which data elements serve as input and output during the interaction. Some use case authors include definitions of the relevant data elements in the use case specification.
Benefits of usage-centric requirements
Use Cases Users Don't Understand If users can't connect a use case to their business processes or goals, there's a problem. Identify the functional requirements that will allow the user to successfully complete each use case.
Playing by the rules
