Telling Stories: A Short Path to Writing Better Software Requirements

Chapter 4. Explaining Processes and Finding Requirements

Explaining processes in a structured way is a great way of capturing and expressing requirements. A structured explanation forces you to think about what makes a process successful, the precise actions of a process, and what is required for success. Explaining processes works best for discovering functional requirements, but don't limit yourself. Feel free to include any type of requirement that comes up—nonfunctional, organizational, businesses, whatever. There is nothing wrong with capturing redundant requirements, especially in a first draft. You can eliminate duplicates in the review cycle.

Every explanation of a process should include the following:

• Names and numbers: The precise name and number of the process being described.

• Success criteria: The essential successful result of the process and how exactly to identify and measure it.

• Started by: The precondition required to begin the process, usually a triggering event. Depending on the type of process, this can also include the data inputs.

• Results of: The end state of the process, including all data outputs, environment changes, and other products of the process that may not be a direct part of the success criteria.

• Elements of: The entities involved in the process, including technical components such as servers and software, but also people or groups.

• Actions in: The series of events or steps that comprise the successful completion of the process, including exceptions to ...