Practice: Detailed Use-Case Requirements Analysis
The main focus of this practice is a first-cut definition of system requirements derived from stakeholder requirements delivered as functional and non-functional requirements. The functional requirements are grouped and prioritized as system use-cases.
Purpose

Value proposition:

  • Enables early collaboration with stakeholders to validate requirements to provide foundation for system architecture.
  • More rapid achievement and more complete set of use-cases and non-functional requirements.

The system specification is the process of designating the blackbox features of the system: its externally visible functionality, what services it provides, and what measures of effectiveness it is expected to meet. It consists of studying how the system is expected to perform in context. That is, the system is considered a participant in a broader enterprise. The system specification follows from an analysis of the enterprise and the role the system plays in enabling the broader enterprise to meet its business purpose or mission. This is the work done with use case requirements analysis. Understanding context is critical in creating systems that accomplish the goals for which they are built.

Understanding context, then, means understanding the interaction of the system with entities external to it (actors), understanding the services required of the system, and understanding what gets exchanged between the system and its actors. Understanding context is also important for ensuring that the appropriate requirements exist or will be developed.

One of the most important contexts to consider is usage, that is, how a system is used, and how it interacts with entities outside itself as it is used. Why? Because our purpose is to develop a system, or enhance an existing one, one of our most important considerations should be that the system is useful. If we can base our designs on the actual usages to which the system is to be put, we will be assured that we build what is needed. After all, systems are built to be used!

How to read this practice

The best way to review a practice is to adopt a multi-prong approach:

  • Use different perspectives driven by artifacts, activities, test cycles, or roles. Shift between them when your focus changes from what you need to produce to how or to when an activity is performed.
  • Start with the related artifacts and decide which ones are important to you and your organization.
  • Analyze the main work pattern, which gives an overview of all of the activities performed as part of a typical iteration.
  • Drill down into each activity to better understand the tasks and artifacts employed.

Also review the guidelines, concepts, and. if applicable, tool-related guidance.

Relationships