Meeting the requirements
By Simon Bisson
Your application may be wonderful, but does it do what the customer wants? Simon Bisson checks out tools that help you ensure it does.
HardCopy Issue: 48 | Found In: Development | Published: 01/05/2010 | Last Revision: 07/07/2010
The newspaper headlines say it all: ‘Massive overspend on computer project’. But when you drill down into the project history you find a story of changing project requirements, rippling their way through the rest of the development schedule affecting everything from schedules through to testing and the hardware being used for the planned system. Because the initial requirements weren’t nailed down and used to define the scope of the project, changes affected everything, with each change to the requirements causing many more to the rest of the project.
Getting project requirements right is one of the foundations of a successful delivery. It doesn’t matter how well you define components and modules, how well you write your unit tests, or how well you handle integration and operation, if you don’t have the original requirements right. Delivering something wonderful and game-changing is all very well, but if you were actually meant to be delivering a billing system, then no matter how wonderful your code is, it’s still a failure. That’s why requirements capture needs to be the very first phase of a project.
Capturing requirements
There are four key types of requirement for any given project:
Business requirements: the overall aims of the project, and how they interact with the business as a whole.
User requirements: user needs and issues that are to be addressed by the project. These can include user interface design guidelines.
Functional requirements: what we normally think of when we consider requirements. These describe the specific behaviours of the application or system being built, along with internal workings and interfaces with other systems.
Quality of Service requirements: these apply to the whole system, and are usually considered in terms of operational performance and regulatory compliance.
Running a requirements capture exercise involves more than asking questions and filling out a spreadsheet. It’s about working with the project stakeholders and users to understand exactly what’s required – from inputs and outputs, to integration points, to storage, to the business logic, to the user interface. Everything about the project needs to be defined before you even start the design process.
If you’re using CASE tools, then requirements capture will be part of the process; if you’re using UML, then you’ll be turning them into use cases; Agile developers will be using the requirements to write their user stories. Designers will also use sketching tools and design comps to capture user interface requirements, along with descriptions of interactions and application flow.
User interviews are only part of the requirements capture process. Formal specifications provide another route for development teams to detail project requirements, mixing user and system needs. If an application is connecting to another, its requirements will include API definitions, along with message structures and sample data. Making sure that all APIs are well defined is essential, as well as ensuring there is a well-understood description of any machine-to-machine workflow.
Refining requirements
Once you have collected all the requirements for a project, you’ll need to engage in a collaborative process with users and stakeholders to ensure that there’s a common understanding of the requirements. This is especially important when determining user interface requirements – you might think that “blue” means the standard #0000FF hex code, where to a user or a stakeholder it’s actually the specific pantone value of one section of the company logo. Documenting and sharing captured requirements will clarify points of confusion, reducing the need for later rework. Clarity is important in your requirements documentation, and this is one place where over-explaining is never wrong. If someone can ask what just one statement means, you’re not stating things clearly enough!
Initial requirements are refined and costed in order to determine the project scope. Not all the initial requirements may be practical, and not all feasible given the cost and time constraints of a project. Building a costing model is complex as it mixes current costs, future costs and development costs. Understanding the effects on the business and on the project of a specific requirement help determine whether it needs to be part of a formal requirements document.
Managing requirements
When you’ve finally agreed the project requirements, and the resulting use cases and user stories, with all concerned, you can start mapping requirements to project modules. This means defining inputs and outputs and using them to define unit and functional tests, as well as putting together user experiences.
The requirements specification may appear to be frozen at this point, but it will remain a living document so it too needs to be part of any change management process. This process will not only reduce the risk of out-of-control changes, it will also ensure that changes are communicated back to stakeholders, keeping everyone involved with the project informed. Changes to the requirements will need to be approved by all project stakeholders along with the development team, ensuring that everyone understands what has been changed – and why the changes have been necessary.
Don’t be surprised if a project’s requirements change. You won’t be able to capture everything in the initial phases of the project, nor will you be able to predict the technical capabilities of a chosen development platform (or development team). Any and all of these will mean changes. It’s how you handle the changes that’s important, as any changes in requirements need to be reflected in the rest of the project. This makes requirements management a key component in any application lifecycle management system you’re using. Requirements management tools are able to link a feature to the group or individual that requested it, so you can go right to the source to discuss changes and to determine development priorities.
The application lifecycle
Requirements management tools map the elements of a requirements document to specific pieces of a project, ensuring that dependencies are understood and that code and requirements are synchronised. They also help define the user interface, mapping requirements to UI components. Test and integration plans are guided by the initial requirements, using them to define acceptance tests and criteria. They also allow you to manage any departure from the original requirement, helping define where code changes need to be made, and how this new code will be tested.
A project’s lifecycle continues long after it’s been released. Faults and deficiencies in the operational code will need to be logged, compared with the original requirements specification, and then used to generate new requirements for future versions – as well as for interim releases and bug fixes. You’ll need to keep the data captured at the start of the project, and use your requirements management tools to generate new requirements from a combination of this and the new data. The resulting requirements will inform and guide the next release programme.
Requirements management tools are widely available, and methodologies are part of key development processes, including CMMI. Ensuring traceability of requirements throughout the development lifecycle is important for the business as a whole, as it makes sure that development practices comply with business regulations such as the Sarbanes-Oxley rules in the US, as well as providing a documented process as part of ISO 9000 certification.
You’ll find a good mix of commercial and open source requirements management tools. While there’s some flux in the market at present as MicroFocus integrates the tools it has recently purchased from both Borland and Compuware, it won’t be difficult to find the tool you need for both small and large projects. Tools can be standalone, or integrate with the two most popular development platforms, Visual Studio and Eclipse.
Visual Studio 2010 Team System
Microsoft’s development tools have evolved from a set of individual IDEs and compilers to a single development platform, with tools for team-based development in Visual Studio Team System and Team Foundation Server. The latest version, Visual Studio 2010, adds more application lifecycle management tools, along with an enhanced set of test management features.
While Visual Studio Team System doesn’t have an explicit requirements management component, its application life cycle management tools, and the Team Foundation Server portal, can be used for this purpose. The tools in Visual Studio give you what you need to ensure the traceability of your project’s requirements, starting with the management of requirements documents created in other applications such as Word or Excel. Tools like Expression Blend can be used to create storyboards that can also be used as a part of your requirements documentation. A SketchFlow storyboard can be used as part of a user story. Use cases can be defined using the Architect Edition of Visual Studio 2010, and then sketched out as SketchFlow prototypes. Screens can be included as case diagrams and will be stored in Team System as artefact elements, tying use case requirements directly to user interface elements.
A query in Visual Studio 2010 Team Foundation Server showing requirements coverage.
Once requirements have been captured and stored in the Team System library, they can be linked to work items. Visual Studio Team System work items can be created using the Team Foundation Client. Once created, work items can be linked to test cases using the new Test Case Work Item Type. Linking test case and requirements helps ensure that requirements can be traced throughout the development process. Test cases can then be accessed from the Test and Lab Manager, where they can be used to ensure code coverage and feature compliance.
How Team System uses work items depends on the development approach you’re using, whether its an agile methodology or a more formal approach. Once you’ve begun the development process, tasks can be defined as the child work items of all the system requirements, so establishing a direct link between a requirement and the code that implements it, and any associated tests.
While Visual Studio 2010 supports requirements management and bakes it into the development process, it’s not a requirements management platform in its own right. You can use it to help codify your own development processes, but these processes need to be in place first: VSTS will conform to your processes, not you to its. Defining requirements early and using them in conjunction with Visual Studio’s unit and user testing tools makes it a lot easier to use a test-first design and development process, which can lead to higher quality deliverables.
Developers wanting to add additional requirements management features to Visual Studio can use tools such as Microfocus’ CaliberRM and Sparx Enterprise Architect.
Sparx Enterprise Architect and RAquest
Sparx’s modelling tools are designed for the cross-platform developer, with support for most common languages and development platforms including Eclipse and Java. Its Enterprise Architect UML tool is able to manage large portions of the application development lifecycle, giving architects the tools to take a project from modelling through to test, and include a set of requirements management and traceability tools.
Viewing a requirements diagram in Sparx Enterprise Architect.
Enterprise Architect can be used to help define an organised requirements model, with a hierarchy that can help with the development of application models. This approach helps with traceability as it allows you to link system requirements to model elements. Once linked, you can search the models and report on the requirements and how they map to code. If a requirement changes, you can use the same search tools to determine its impact on the models, and on the resulting application.
Architects can use the report features in Sparx’s tools to convert models into documentation. This is an important tool for requirements traceability as it allows architects to show stakeholders how project requirements are being implemented as features and components.
You can add futher requirements management features to Enterprise Architect using Sparx RaQuest. This adds support for more complex requirement items, including support for multiple features per requirement, as well as providing change management for requirements. RaQuest uses a matrix view of the system requirements to show how the relationships between requirements will be changed.