Home 
CM Journal Articles Thinking Outside the Box: What if You Managed Requirements at the Object Level?
CM Journal Articles Thinking Outside the Box: What if You Managed Requirements at the Object Level?
|
| Every year, countless software development projects are delayed, over-budget and cancelled, largely because they lack a sound Requirements Management process. As James Martin wrote in Information Manifesto, at least 56 percent of project defects can be traced to the requirements process, which at many companies is flawed, informal or even non-existent.
Most companies initiate requirements management by writing a document that defines the system in detail, including what functionality the system should provide; its system properties such as performance, reliability and efficiency; and constraints on operation and development of the system. The document serves as the official statement of the system requirements for all stakeholders, which may include customers, end users and software developers and is commonly referred to as the functional specification, the requirements definition, or the software requirements specification (SRS). In many instances, requirements management is more focused on writing and completing the document than on ensuring the completeness and consistency of the requirements prior to development. And attempting to manage requirements through a document can be very time-consuming because of frequent change. So instead of collecting requirements into documents, imagine if each requirement were treated as an object with specific attributes and behaviors. Treating requirements as objects results in: Visibility - Requirements can be viewed, sorted and filtered on an individual basis as opposed to being buried in a document, providing a mechanism for clearer elicitation, analysis and communication. Reusability - Requirements can be re-used from one project to the next, which provides for versioning of requirements within a software project that has multiple releases. Testability - Each requirement can have its own verification and validation criteria, resulting in a high level of quality for each requirement that is propagated across the entire system development process and allowing the testing process to be initiated earlier in the software development lifecycle. For example, each requirement can be traced from its inception to its deployment in the delivered system such as its related system requirement(s), test requirement(s), designs and program or component module, allowing impact analysis to be conducted easily any time a change to a requirement is identified or anticipated. And once the impact of the change has been identified, stakeholders immediately know what components related to the changed requirement need to be changed or replaced. In addition, each requirement can have its own individual change history and level of security. This identifies who made the change and the reason for the change, rather than forcing stakeholders to review a specification document annotated with change bars. Furthermore, several pieces of information of various data types can be stored for each requirement. In addition to a text-based description, each requirement can be linked to other objects like process models, use cases, spreadsheets, documents and test cases. What if Number 2: What if requirements could be captured at their source instead of being gathered and translated from one source to another? Writing the requirements specifications remains the most difficult and time-consuming aspect of requirements management. And with the new focus of developing and delivering global systems via the Internet, this process has become even more complex, since cultural, language and geographical differences must be addressed. Having stakeholders write their own requirements may be ideal, but for most organizations it’s not realistic because they often do not know what they want from a computer system, and even when they do, they struggle to communicate their desires. What’s more, often stakeholders express requirements in very general terms that can be easily misinterpreted while others may also have domain knowledge that they fail to express when specifying requirements. Lastly, stakeholders often use their own terminology, which introduces a new set of challenges when others are trying to interpret. Business or systems analysts are usually charged with writing requirement specifications, attempting to understand and interpret what the stakeholder actually wants or needs through interviewing, brainstorming, facilitated sessions and more. But to minimize the time needed to elicit and define requirements, and reduce error, the analyst needs a way to initially capture the requirements. Therefore, collaborative stakeholder involvement ensures requirements are expressed in their own words as well as the number of times a requirement is reviewed before it is considered complete and correct. As Lutz Easterbrook wrote in Experiences using Formal Methods for Requirements Modeling this process can help to mitigate errors including undocumented assumptions; inadequate requirements; traceability and inconsistency; imprecise terminology; and logical error. What if Number 3: What if requirements were stored in a central repository? The majority of companies store their requirements in Microsoft® Word® documents or Excel® spreadsheets with more sophisticated organizations using departmental databases that may include Microsoft Access® or Lotus Notes®. But even when an organization has a more mature approach, all projects rarely use the same approach. Managing requirements in a centralized repository greatly improves the requirements management process because it initiates the standardization and sharing of requirements across all projects. Requirements can be easily traced from inception through deployment and maintenance, providing a collaboration mechanism where conversations among stakeholders can be associated with individual requirements. Most importantly, it provides more effective and efficient impact analysis, trade-off analysis and risk analysis of requirements. What if Number 4: What if stakeholders were automatically notified when a requirement changed? Defining requirements is a continuous discovery process, usually starting with high-level or abstract statements of the users’ needs before further refinement, analysis and definition occurs as more becomes known about the problem to be solved. Therefore, by their nature, requirements are dynamic and it’s safe to say that requirements can and will change. So when they do, it’s critical that affected parties are notified of any change immediately. Requirements stored in documents present two challenges to notifying stakeholders. First, the individuals making changes may not know everyone who is affected by the change. Secondly, even when they do know who should be notified, they can’t always ensure notification will be accomplished quickly. In most cases, notification is done verbally or by re-publishing changes to the specification document, approaches that are both time-consuming and relatively ineffective. But when requirements are considered as individual objects, it makes it easier to identify who is responsible for each requirement and who should be notified when it changes. Using an electronic form of notification, such as e-mail, to distribute changes ensures that notification is accomplished quickly. The electronic change notification should inform the stakeholder of who made the change, what was changed, why it was changed and when it was changed. When this approach is combined with requirements traceability, impact analysis of the change also can be easily accomplished. Choosing the Right Technology After the outside-the-box thinking has you treating requirements as objects, defining requirements at their source, storing requirements in a centralized repository and automatically notifying all affected stakeholders any time a requirement changes, the next step is to consider what technologies will support its implementation. The technology selected must support an organization’s best practices for system development, with every organization handling requirements management differently. Based on the scope and complexity of a project, the time and activities allocated to requirements management can span a wide spectrum. Since the project manager is ultimately responsible for all requirements, the technology must also not add to an already daunting list of tasks, allowing the project manager to effectively control the scope of the project and easily assess the impact of changes to requirements and the project schedule. The technology should also be easy to use and fit into a familiar context for a variety of stakeholders to learn and incorporate into their routine software development activities. For example, if it’s to be used by developers, it should be robust enough to support daily usage. Lastly, the technology must simplify generating and distributing specification documents since they will always be needed to support the new process. Distributing documents via the Internet is the way distributed development teams work today. Four proven technologies can effectively and efficiently support the re-engineered requirements management process, including an object-oriented database that is easily customizable and provides a central and secure repository for requirements definition, analysis and traceability; an Internet-based tool that provides visibility, collaboration and immediate electronic change notification; an easy-to-use graphical user interface based on Microsoft Windows, Word, and Windows Explorer;® and a customizable document and report generation and electronic distribution tool. A requirements management tool that tightly integrates these four technologies will provide the project team with an efficient and effective way of managing all requirements from inception through deployment. Conclusion The answers to the “what if” questions emphasize that requirements management now includes controlling, managing, tracking and communicating changing requirements. And instead of perceiving requirements as specification documents, requirements are now viewed as re-usable objects that can be assembled into a specification document at any point in time to accurately reflect the current version of requirements. By thinking of requirements as objects it helps support a collaborative process for distributed development teams by providing an “electronic meeting room” for reviewing, collaborating and approving, which is especially helpful when development teams work in different time zones. It can also speed up the development process through re-use of requirements and can minimize the number of times a requirements specification is reviewed before it is approved. Additionally, it provides a basis for test planning to begin in the early stages of the systems development life cycle, a repository for standardizing cross-project reporting and an automated means of doing impact and “what-if” analysis. Changing the requirements management mindset of an organization from being document centric to object centric requires time and commitment to re-engineering the process and training the organization. However, the long-term benefits to the organization far exceed the time and effort spent in getting there. As the research arm, Gartner Group, has written: “Automated requirements environment will better support change control efforts, gain testing efficiencies and potentially reduce their future maintenance burden.” Mr. Hunter is responsible for Starbase's product engineering, quality assurance, quality control programs, and MIS/IT departments. Mr. Hunter has over 15 years extensive experience in product strategy, managing software development projects, quality assurance, and team building. Mr. Hunter was most recently the Vice President of Engineering for Mustang Software, Inc. Mr. Hunter holds a BS in Computer Science and minor in Economics from the California State University. You can reach Mr. Hunter by email at Scott.Hunter@Starbase.com
Set as favorite
Bookmark
Email this
Hits: 3977 Trackback(0)Comments (0)
|
| Last Updated on Sunday, 05 August 2007 17:18 |
TrackBack URI for this entry
Subscribe to this comment's feed