Note: This is Part 1 of our discussion concerning going from system concepts to requirements. Part 1 addresses the basic concepts; Going from system concepts to requirements – Part 2 delves more into the “How” to go from system concepts to requirements.
As you know, before writing requirements there is a lot of work that needs to be done. Of prime importance is working with the various stakeholders to understand and document their expectations. Remember, requirements are the means of communicating stakeholder expectations to the designers. These expectations may be captured in the form of system concepts which include stories, scenarios, use cases, operations concepts, concepts of operations, etc.
This leaves a key question: “What is the relation between system concepts and system technical requirements?” The best way to communicate this difference is through the following example:
Your company has a need for a system to better manage its customers and you have been assigned the task of writing the requirements for this new system. One of the first things you do is understand what it means to “better manage” customers. So what do you do? You speak with the stakeholders and get their perspectives, their expectations for this new system and then you come up with several expectation statements concerning functionality, performance, and quality of the system.
- “The salesman should be able to create a new user record” with several more detailed statements concerning the “create new user” function.
- “the salesman should be able to input one or more phone numbers for the new client”,
- “the phone numbers will be types: home, work, mobile, …”,
- “the system will control the format of the phone number” … etc…
- The salesman should be able to update an existing customer record”
- “the salesman will be able to select an existing customer”
- “the salesman will be able to update an existing customer’s information”
- “the salesman can filter the set of customers by name, surname …”
In general, the activities (functions) can be related to a scenario or Use Case, which can be decomposed into subfunctions and performance expectations, e.g. select a customer record, create records for xx number of customers, validate the customer data, update customer data, etc….),
So, how do you go from these system concept statements documented in the form of use cases and written from the perspective of the stakeholders to the technical requirements for the system to be developed?
In use case terminology, there are actors involved in performing a function. For each use case, we like to see a set of scenarios for each major function. Ideally, this set of scenarios usually contains a nominal scenario, one or more alternate nominal scenarios, and one or more off-nominal scenarios (e.g. what if the system crashes during a major update, what needs to happen?)
Oh, and the bad news…use cases are NOT requirements on the system. Use cases are a source of requirements, but not the actual requirements. Use cases describe the interaction between the actors and the system to accomplish a given function. From the use cases, we can derive what the system needs to do to enable the actor to do what he/she needs to do using the system. The system has to enable the actor to perform the needed functions. That is the reason for the system.
Use case scenarios are used as a tool to help the various stakeholders (actors) communicate their expectations for accomplishing their needed functions using the system under development. In the example above, the salesman needs to be able to create a new customer record (including phone numbers along with other data); to update an existing customer records; filter the set of customers, etc. Create, Retrieve, Update, Delete, Filter, Report are the functions the stakeholders need to do and it is the system under development that will allow them to perform those functions.
It is a common mistake to add a “shall” to a use case statement thinking it is now a system requirement. You never want a system requirement on a user, i.e., no “The user shall be able to ………” requirements. The phrase “be able to” is ambiguous, it is a phrase that should never appear in a system requirement statement. (See our blog “Avoid using “be able to” and “be capable of””). Well written system requirements are written in active voice and have the form “The system shall [do something]. Where {do something} is written in unambiguous, verifiable wording.
We like to develop system requirements from the system concepts using a “Column A, Column B, Column C” approach. Under this approach, column A consists of statements from the stakeholder’s perspective. “The salesman needs to create a new customer record” is a statement that would be in column A. As shown in the example you can decompose this statement into subfunctions and performance expectations under the main function in column A.
We then ask, what does the system need to do such that the salesman can create a new customer record? The answers provide us with what we document in Column B. Column B reflects what the system needs to do such that the salesman can do the functions/subfunctions and actions in Column A. The statements in Column B can be a bulleted list to start with. “The system needs to include a method to store customer records.” “The system needs a definition for what a customer record consists of”. “The system needs to provide a user interface.” “The system needs to provide security to control access to the customer records.” etc. Again, Column B is focused on what the system needs to do.
Column C is used for the cases where the system needs to interact with another system to fulfill its tasks. Thus Column C includes other systems our system has an interface with. For the example, our system needs a method to store customer records, so we would list in Column C a database that is available. The format and structure of the user records would be part of the definition of the interaction between our system and the database system, the interface. In Column B we would have statements concerning the interaction of our system with the database (write data to, request data from type statements that clearly communicate the specific interaction).
So the answer to the question concerning the relationship between stories, scenarios, use cases, system concepts, etc, is that there are expectations for each major function (process) from each stakeholder’s perspective that are communicated via a set of scenario statements in Column A. What the system needs to do so the stakeholder can perform needed functions is derived from Column A and documented in Column B. From the statements in Column B, you can then write your “The system shall…” technical requirements that will be provided to the designers.
We hope this helps. In “Going from system concepts to requirements – Part 2” of this discussion, we explain the “How” associated with going from the Column A stakeholder perspective to the Column B system perspective.
