Visual Models for Software Requirements: Selecting Models for a Project
- Selecting Models by Project Phases
- Selecting Models by Project Characteristics
- Thinking About the Audience
- Tailoring Models
When I decide to work on a project around my house, I start by selecting the tools to use. I first consider what type of project I’m doing and then consider what step in the overall project I’m working on, so that I can pick the right tool. For example, if I’m cooking, I use tools such as a mixer, measuring spoons, a rolling pin, a frying pan, and a spatula. I can further narrow my tool selection by the type of cooking I’m doing. If I’m baking, I would more likely use a mixer than a frying pan. Finally, I pick the tools I need based on which steps in my cooking project I’m executing. Initially, I use measuring spoons and cups, then I use a mixer, then I might use a spatula or rolling pin, and finally I might use a baking dish and cooling rack near the end.
On the other hand, if my task is to build a bookshelf for the house, I would select different tools than those I use for cooking. I could use a hammer, a screwdriver, a saw, nails, and screws. Similarly, I can further narrow my tool selection at any point based on the step I’m at in the project. Early in the project, I might use a saw to cut the wood, but later I would use the hammer and nails to assemble the bookshelf.
To select tools for projects around my house, I determine what I’m trying to accomplish and then decide which tools best help me meet those goals. There are many RML models, and selecting the right models to use for specifying a solution is similar to selecting tools for home projects. The task can be overwhelming if all you have is a list of models without a framework to help you narrow the list.
This chapter will help you select models for your project based on the project phase you are executing and the project characteristics. For each of these factors, we overlay the model categories to ensure that you consider all types of models.
Selecting Models by Project Phases
Models are a key component of every stage of the software process. It’s important not to lose sight of the overall project approach and become bogged down in the minutiae of creating models, but rather to understand how the models fit into the approach to ensure a complete set of requirements during the entire development cycle. Figure 25-1 shows a generic requirements process and the activities that occur within each phase. The phases are envision, plan, develop, launch, and measure. Within each phase there are requirements-based activities. These process phases map to phases in virtually any development approach (such as waterfall, iterative, agile, and custom approaches). The focus is on the activities within the phases rather than how the phases are executed. The key is that no matter what your development approach is, within each phase there are activities that benefit from using requirements models.
Using the appropriate models helps all stakeholders understand the requirements so that nothing important is missed and only the requirements that are important are implemented. The following sections further discuss the role of models in each phase of the requirements process. Although these are described in an order similar to a waterfall approach, they can be applied in any development methodology.
The information from the following sections is summarized in a table in Appendix A, “Quick Lookup Models Grids.”
Figure 25-1 A requirements process.
The Envision phase occurs before a project is actually chartered. Executives who own corporate strategy and manage a portfolio, program, or product roadmap have to determine which projects to fund based on the value they add to the organization. This phase determines how the project supports the corporate or program strategy, what value the business stakeholders will receive from it, and what high-level features the stakeholders need to achieve that value.
During the Envision phase, a business analyst helps executives explore the business problems, determine the business objectives that all requirements eventually map back to, develop the business case for the project, and set a broad scope for the project. The business problems and objectives are captured in a Business Objectives Model, and the highest-level features are captured in a Feature Tree. The business objectives enable business analysts to determine the project’s priorities, which will be used throughout the entire project to help the team make decisions when cutting scope or when trying to decide which features to develop first.
You should also create initial high-level models such as Org Charts and Ecosystem Maps. Org Charts are a great starting point for creating people models, because they offer the opportunity to consider every single person or role that might affect or use the system. Though Ecosystem Maps do not identify specific requirements, they do identify the interfaces for which to elicit requirements and the systems that might be affected by the project. In addition to models, you should create an issues list to log every outstanding requirements-related unresolved issue or question. If you are not using a requirements management tool, then typical documents that you might produce during this phase might have names such as “business case,” “business requirements document,” “marketing requirements document,” “product backlog,” and “vision scope document.”
During the Plan phase, you are trying to determine how the software needs to work so that it will achieve the value expected by the business. By listing out all the requirements, including the functions the software needs, the business rules that influence the functions, and the non-functional qualities, you will create a complete list of requirements that your business stakeholders, developers, and testers can use to build, configure, or test the system to ensure that the business value is achieved. Identify which models are needed based on the characteristics of the project, and define a requirements architecture (described in Chapter 26, “Using Models Together”). Finally, you might select tools to create and store models that support the requirements architecture, and create a requirements plan that outlines when each of the models will be created in relation to the others.
You should test out your requirements architecture and process on a portion of the project, adjusting it as you determine what works best for your organization. Project priorities can change; analysts might find that the choice of models is not sufficiently capturing requirements, or a variety of other reasons can force the team to alter the requirements architecture. In these scenarios, it’s important to review the already created requirements and models to ensure that no additional artifacts need to be created or existing ones altered; changes to the requirements architecture often affect prior work.
This phase is where you will do most of the elicitation and analysis to complete models, working from a high level to more detailed models (see Chapter 26 for more about this). You also should derive requirements from models. In addition, you should continue to update your requirements issues list as you determine parts of models that you cannot yet complete.
During this phase, you might create a Key Performance Indicator Model (KPIM) to articulate how the project will improve or at least maintain the throughput of the business. You will also create Objective Chains to determine the scope of the requirements. You should create Business Data Diagrams (BDDs) and Process Flows to define and bound the project scope. The remainder of the models you need on the project will typically be created in this phase.
Further, you can use the Business Objectives Model to prioritize the analysis work you have to complete. If you are not using a requirements management tool, examples of documents that you might create during this phase include business requirements documents, system requirements specifications, software requirements specifications, functional requirements specifications, sprint backlogs, and user stories.
After the models have been created, validated, and verified, the next step is to ensure that the development and testing teams understand what they need to build. Developers and testers will use models and corresponding requirements and business rules to build code, configure existing systems, and develop test cases. During your model creation, you should have derived requirements for most of the models. This is the phase for which it is most important to have done that step, because developers and testers have an easier time knowing that their job is done when they have a list of functional requirements and business rules that they can use as a “checklist” rather than just a model to build and test from.
During this phase it is important to fully explain the usage of the models to these teams; otherwise, the models might be interpreted and used in a manner for which they were not intended. For example, developers might use only the Use Cases and not look at the requirements if they do not understand how the two fit together. Further, they might look at only the requirements and not the models, missing the important context you set with the models.
It is common for this phase to also include steps for updating models that are now in a “locked” state as changes occur. This means that all changes to requirements and models must be approved and communicated to teams downstream of the business analysts because those teams might have created artifacts using those requirements and models.
During this phase, you should be maintaining your issues list as well as updating all documents and models as necessary. You should be engaged with the developers as they build the solution, and with testers as they ensure that the system is built properly. Your role is to clarify how the software should work, update priorities, and ensure that what is being built works the right way. No matter how well you document the requirements, there will always need to be verbal clarifications, especially as you get into the details of the business rules, usability, and detailed functionality of the system. As you explain the functionality, you will most often be using models to help other team members understand the context. For example, you could use a Process Flow to help the developers understand what the user is trying to accomplish, then use a BDD to explain how the business thinks about the data elements. During the development phase, you will be updating your existing documents and might create documents such as “user acceptance tests” or versions of previous documents tailored to specific development teams.
During the Launch phase, the business stakeholders confirm that the solution meets their needs. They can use Process Flows and Use Cases to create user acceptance tests to perform this verification. When the system has stabilized to the point where the business evaluates and accepts the solution, it is ready to be deployed. Process Flows, Use Cases, Roles and Permissions Matrices, and Display-Action-Response (DAR) models can be used to create training materials for the new system. Typical documents created during this phase could include training manuals, user guides, help files, and any other materials that will ensure that users have high satisfaction and adoption rates.
The Measure phase takes place after a new system is live and the users have adopted the system for their use. During this phase, analysts can measure the return on investment of the solution’s business objectives and use key performance indicators (KPIs) to truly determine the value that the project brought to the organization. By using real data and a live measurement, it is possible to confirm that the business objectives set at the start of a project in the Business Objectives Model were actually achieved. Furthermore, the organization can measure individual business processes to ensure that they have met KPI targets described in KPIMs. Documents created during this phase might include presentations to executives describing the return, lessons learned documents, or retrospectives.