In my previous post, I described a default architecture for a UI application. In this post, I will introduce the concept for a system that requires a UI application (as well as other software packages) and briefly describe a process for discovering system requirements (user stories, scenarios, and feature specifications). Once the system requirements are defined, and using system architecture guidelines like the one in the previous post, product requirements can be defined.
The first step in a project’s life-cycle is the establishment of a project charter. Given that this is a fictitious project, there isn’t a real project charter. However, I did create a wiki (warning: be sure to have an ad blocker running) to keep track of some overly simplistic artifacts to use as a place to keep my ideas straight as I walk through the process of developing this conceptual project. Included in that wiki, is the Circulade Project Charter.
The overview of the Circulade system is to create a platform for enabling people trying to ship cargo to connect with carriers trying to fill their cargo containers for a route. This connection will allow shippers to find better shipping rates by finding containers with available space that can be purchased at a discounted price compared to standard shipping rates. Carriers will be able to make more money by selling space that would otherwise be left empty on an already planned shipment.
Once a project charter has been approved by the stakeholders, the project initiation process begins. However, since I want to keep focused on the deliverables of a project, I won’t be describing that process. For more details on project management, see the following:
- PRINCE2 (overview) especially their Processes Tutorial
- PRINCE2 (main site)
- Understanding Lean Project Management
To use terms from the PRINCE2 methodology, this post will be focused on the procedures in the Managing Product Delivery process. The “work package” to be delivered is the System Requirements for the project. This is accomplished by applying the business analysis process. The initial delivery of the System Requirements will consist of the most prominent User Stories and their most prominent Scenarios along with a list of Features the project will be expected to deliver and the Quality of Service requirements that will constrain the delivery of those features.
Business Analysis Process
System requirements specify the features a system must have in order to assist users with completing processes. These processes are described as Scenarios which detail a specific set of steps that are used to accomplish a User Story’s goal. Scenarios and User Stories are referred to as Business Requirements.
It is beyond the scope of this post to list all of these requirements, especially since this is a fictional system. However, the wiki contains some examples of the user stories used to produce this project.
If this were a real business, a Business Analyst would work with subject matter experts to elicit and document User Stories. More in-depth descriptions of user stories can be found at the following links:
- BA Times article
- The DSDM Agile Project Framework (scroll down to section 15.3)
- Five Rules for Writing Effective User Stories
- IIBA Agile Extension to the BABOK Guide (pdf – link should go to section 188.8.131.52)
For each user story, the analyst further examines the processes and procedures required to accomplish the goal of the story. This examination results in Scenario descriptions.
A scenario describes the process an actor must step through in order to achieve a goal . It specifies what information is needed, what decisions must be made based on that information and what to do with the result of those decisions. Another way of thinking about scenarios is to consider them “user flows” or “use cases”.
For existing organizations with detailed business process and procedure documentation, this activity is much easier, as the scenarios are essentially the process descriptions or are slightly modified versions of them as projects are usually intended to provide a new or improved process for the organization.
Again, some simplistic examples can be found on the Circulade wiki.
For more detailed examinations of the scenario writing process, read the following articles:
- On Writing Feature Requirements
- Information & Design: Scenarios
- How to Write a Useful Scenario Walkthrough
- Creating the Business Scenario
Based on the Project Charter, User Stories, and Scenarios, a business analyst can specify the features a system must provide in order to enable the users to more efficiently accomplish their goals. For each Feature, a set of Feature Requirements will be defined.
This post provides a good example of the difference between a Feature and a Feature Requirement.
Quality of Service
QoS requirements are non-functional requirements such as availability, maintainability, extensibility, etc. These are important to capture in order to meet the expectations of the users and the stakeholders. The FURPS+ system is a useful way of thinking about these types of requirements in order to elicit these needs from the stakeholders and subject matter experts.
For the Circulade project, the system requirements examples are on the wiki.
Solutions Architecture Process
With the first batch of system requirements defined, a solutions architect, along with a user experience architect, should analyze the business requirements in order to identify any subsystems, or natural boundaries, within the organization and use these bounded contexts to define deployable packages of software/hardware necessary to fulfill the business requirements of the subsystems. This analysis is best handled by using the principles described by Domain-Driven Design. For a deep dive into these principles, see the following resources:
- Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
- Implementing Domain-Driven Design by Vaughn Vernon
- Domain-Driven Design Reference: Definitions and Pattern Summaries
- Udi Dahan’s blog has several articles on the subject
- Greg Young has also authored several articles on the subject, such as:
Once a bounded context has been identified and the software/hardware requirements are being determined, if the context requires a user facing application (and almost all of them do), the architects design the wireframes of the UI screens and detail the information needed for display and manipulation.
The solutions architect uses the system requirements analysis along with the wireframes and information details to specify the product requirements as a set of interface definitions.
The next post will explore the product requirements for the Circulade system’s public context.