Business white paper Seven best practices for business-ready applications
Table of contents 3 Executive summary 3 Introduction 3 Enterprise-level best practices 5 Project-level best practices 7 Build better software 8 Conclusion
Executive summary One of the keys to developing applications that meet business requirements is to define the right requirements up front. Requirements need to be clear and succinct, but they also must incorporate feedback from multiple stakeholders. Enterpriselevel and project-level best practices in defining and managing requirements are presented to help projects meet intended business metrics. By eliminating the gaps between work processes performed in IT silos, teams can rapidly deliver applications in response to shifting business requirements. Introduction One of the biggest barriers in building applications that meet business needs is the inability to capture well defined business requirements. When requirements are defined by one individual or a group of people to meet the needs of a different set of users, some information can be lost in translation. When this happens, defects can be inadvertently introduced into an application early in the lifecycle, and the defects may not be discovered until much later when it is more expensive to fix them. In fact, many project budgets are consumed by rework when requirements defined early on need to change as business needs change. As project teams become more geographically distributed (due to outsourcing, mergers and acquisitions, and other factors), communication becomes more difficult, and this problem is exacerbated. In addition, cloud, mobile, and composite applications bring greater complexity to the requirements process and the applications themselves. With rapidly shifting business needs, many organisations are adopting Agile development techniques that involve tweaking requirements based on feedback from stakeholders as the project progresses. These changes must be tracked and communicated to all team members in real time and may impact a previously approved requirement. Enterprise-level best practices The first three best practices are implemented at the enterprise level. Through enterprise-wide standardisation, a common language and traceability, and creating well-defined requirements that provide consistency throughout the application lifecycle become part of the corporate culture. Enterprise-wide standardisation: Standardise requirements management at the enterprise level to promote collaboration and eliminate silos between business analysts, development, and quality assurance (QA). A single system for complete requirements management provides a definitive version of the truth for project teams to find the most up-to date information. This is particularly important as requirements change over time, either because of changing business conditions or by design as part of an iterative development process such as Agile. A single requirements management system also enables better oversight, giving the VP of applications and other executives visibility on requirements completion. Common language: Provide consistent guidelines for the language used for all requirements to make requirements easier to write and follow. This prevents both the overwork of adding more detail than necessary and the extra time needed to cycle back for more information when descriptions are too vague. We recommend guidelines that call for: Using simple, imperative sentences (e.g., include only flights from origin to destination on the departing flights list.) Using the present, indicative tense; in other words, consider adding an s to the verb. (e.g., The system requires a single sign-on.) Avoiding semicolons or conjunctions (and, or). Keeping one requirement per sentence makes it easier to measure and delegate development and testing work. Avoiding can or may statements. Requirements using these verbs will be too vague. Faced with these challenges, how can IT organisations deliver applications that are more aligned with business needs, budgets, and schedules? This paper will explore best practices both at the enterprise and project level to capture and manage welldefined application requirements. These practices help teams that use Agile and other iterative processes as well as those using traditional waterfall methods. Improving requirements definition and management processes helps reduce the time required to deliver software projects and increases the likelihood of their success. 3
Following these guidelines not only makes the requirements more robust and easier to follow, it also enables measurement of the quality of the requirements. These quality metrics include: Lines of text the number of lines of text in the requirements document. When there is uniformity in the way requirements are described, this metric allows the user to estimate the functionality and degree of testing required for the software. Imperatives the number of imperatives in different categories, such as shall, must, and will. The number of imperatives gives a rough estimate of the degree of design functionality required in the software. It also gives an estimate of the degree of testing required to satisfy these imperatives. Weak phrases the number of weak phrases such as large, fast, enough, etc. Weak phrases indicate vague design requirements that are non testable. Completeness the percentage of requirements that do not contain phrases such as TBD (to be determined) and TBS (to be specified). Requirements containing these phrases are considered incomplete. Option phrases the number of phrases such as can, may, I/we think etc. These indicate requirements that might be difficult to satisfy in development. Another best practice to encourage the use of a common language for requirements is providing a template or set of templates for requirements definition. Traceability: Enable traceability throughout the application lifecycle to determine whether the current project meets requirements. The ability to bi-directionally trace links between requirements and tests, as well as between requirements and code, allows business analysts and other stakeholders to make sure that IT delivers what the business expects. It makes requirements the basis for testing the application, which enables the QA team to test against criteria defined by the business. For developers, requirement-to-code traceability enables opportunities for re-use if similar functionality is needed across different applications. For the QA team, traceability ensures a record of test case coverage associated with business requirements, which is essential for defect reporting. For the vice president of applications and other management, traceability provides visibility into the progress metrics that matter most how well the application meets the needs of the business. Traceability metrics include: Requirements traced the number of requirements traced to or from each specification Requirements untraced number of requirements that are not traced Requirements inconsistently traced number of requirements inconsistently traced Linkages number of upward and downward linkages for each requirement. This helps determine re-use and the impact of changes on the overall application Coverage per cent of requirements traced to passed tests, failed tests, or tests not run 4
Project-level best practices The next four best practices occur at the project level. Adopting these practices brings clarity to the requirements process and helps eliminate rework in the development and testing of applications. In addition, these steps help eliminate overwork and rework in the requirements definition process itself. Be lean: Do not create requirements assets unless they will provide value to the application team. The assets with the most value will be the ones that can be re-used. A lean approach includes automating processes and eliminating waste. By systematically organising requirements, it becomes easier to see which requirements are needed and which can be eliminated. Standardising on the content of requirements with templates and a common language helps make requirements easier to understand and eliminates rework. Iterate: Create requirements iteratively to generate feedback, promote collaboration, and enable teams to identify defects early in the software development lifecycle. A best practice is to start the process with a high level business requirement by describing who needs the functionality for what purpose and why. Then, rather than working in isolation, the business analyst writing the requirement should go back to major stakeholders to get feedback on whether the high-level requirement adequately describes the business need. Developers should also provide feedback on whether there is enough information to get coding started. If not, the business analyst should drill down to add more detail. But if there is enough information, the developers should get started. Figure 1 HP ALM Coverage Analysis provides real-time traceability to all lifecycle assets, including tasks, tests, and defects. Different requirements will require different levels of detail. Save time and reduce complexity by providing just enough elaboration. There is no need to over-describe requirements that are easily understood. 5
As a project goes through iterations of requirements definition, it is important to measure where and how requirements change over time. Change metrics include: Volatility the number of requirements added, deleted, and modified, classified by a reason for change. Initial allocated requirements the number of technical and nontechnical requirements originally provided by the customer. This metric, along with final allocated requirements and changes per requirement, describes how much requirements change. Final allocated requirements the number of technical and nontechnical requirements that were used to build the final software product. Changes per requirement the number of changes made to each requirement. Changes over time number of changes per week, for example. This describes the degree of volatility of requirements. This number should decrease towards the end of the software lifecycle indicating convergence of requirements. Cause of change categorising the cause of changes helps in identifying the most common reasons for change and can be used to improve the software process. Source of change identifying the source of change (i.e., who requested the change), helps anticipate the sources for change in the future. Visualise: Sometimes a picture really is worth a thousand words. Use visualisation to increase understanding of requirements as well as the dependencies between requirements. Visualisation makes it easier to identify potential problems such as missing use cases. Pictures can be easier to read and navigate than text-based requirements. For teams that do not want to follow the Agile practice of writing code early in the process, visualisation and simulations can be used to elicit early feedback to achieve many of the same objectives. Collaborate: To get requirements right at the end, collaborate and break down silos between groups from the beginning of the process. For instance, while a business analyst might have the end user view of what a requirement should be, collaborating with the development team will provide the perspective of whether the requirement is feasible to implement. Figure 2 Requirements assets that can be re-used, such as business process models (BPMs) that can be used to generate requirements, provide the most value. 6
Build better software HP Application Lifecycle Management (ALM) is a unified, scalable platform that enables IT to manage the application lifecycle and connects the delivery of applications from project proposal through operations. It provides full requirements management functionality in a single system to enable alignment of project teams. HP ALM enables teams to: Use templates for requirements and import original source material in formats familiar to business analysts, including Microsoft Word and Microsoft Excel documents. HP ALM provides an editor with full word processor capabilities (similar to Microsoft Word) for editing use cases and structured requirements. Trace requirements to project plans and build key performance indicators (KPIs) for the requirements process. Coverage analysis provides real-time traceability to all lifecycle assets, including tasks, tests, and defects. Automatically generate a test plan framework from requirements with full traceability to enable the QA team to test what matters most to the business. HP ALM automatically generates business requirements documentation in custom formats that can be distributed to management and other appropriate members of the organisation. Figure 3 Pictures and UI mockups can be easier to read and understand than text-based descriptions. Re-use requirements assets via integration of HP ALM with many third-party tools. Business analysts can import user interface (UI) layouts and mockups as well as any business process models (BPM). HP ALM identifies all project paths of a BPM, and automatically generates requirements for each path and step in the model, saving time over manual translation efforts. Manage data requirements by attaching data tables from Microsoft Excel. HP ALM supports the clear organisation of requirements with the ability to list functional, non-functional, and data requirements. Take an iterative approach to requirements definition using version management at the requirement level and across the entire process. Create and compare baselines to identify changes between builds, cycles, and efforts. HP ALM provides the ability to graduate requirements from initial concepts to real requirements with proper validation. Use many forms of visualisation for requirements including business process models, screen mockups, data flow diagrams, and capability maps. Collaborate with other teams using a single system for complete requirements management with Web-based, global access. HP ALM provides version management of all requirements artefacts in a redundant repository for joint access and collaboration across teams. HP Requirements Management is built into HP ALM to provide a single, browser-accessible platform for business analysts, project managers, designers, developers, testers, and the vice president of applications. Requirements that are managed in HP ALM are visible to all key stakeholders throughout the application lifecycle and are readily available to developers within the most popular IDE environments, such as Microsoft Visual Studio and Eclipse. Dashboard views for all stakeholders can be represented in terms of the relationships to requirements (such as being able to determine which developer source code modules or test cases address which specific requirements). This provides business context to all application delivery areas. Because changes in a requirement can have a significant impact on other requirements and in turn, code and tests, these changes can be managed in HP ALM in real-time. Any of these changes can also be reversed because the entire system has version control at the field level, which is critical for global collaboration. 7
Conclusion When these best practices are implemented, projects are more likely to meet intended business metrics, including budgets, schedules, and client satisfaction. By eliminating the gaps between work processes performed in IT silos, HP ALM helps IT teams to rapidly deliver applications in response to shifting business requirements. A global health care company recently improved requirements management in their ERP environment. With HP Requirements Management, they were able to: Specify and link requirements, making it easy to establish and identify relationships between requirements. Tie requirements to test cases and code, establishing a traceable link to the corresponding requirements definition. Link defects to test runs, to see which requirements are impacted by drilling down to the test run, test case, and to the linked requirements. Provide a visual report detailing the status of all tests to identify quality levels and risks. Transition to a paperless requirements documentation environment. This enabled the applications team to provide more complete traceability, facilitating that they developed against their requirements and successfully tested them. By empowering the business analyst, development, QA, and project teams to communicate and collaborate, they have a better understanding of what they need to accomplish, which leads to software that successfully aligns with business and user expectations. Project failure due to poorly defined requirements can hurt your business. Track quality, avoid rework, and deliver what the business asks for; visit: hp.com/go/rm. Get connected hp.com/go/getconnected Get the insider view on tech trends, alerts, and HP solutions for better business outcomes Share with colleagues Copyright 2011-2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Microsoft and Excel are U.S. registered trademarks of Microsoft Corporation. 4AA3-6360EEW, Created October 2011; Updated April 2012, Rev. 1