Training the Software Requirements Engineer

What are different type of training required for a Software Requirement Engineer?

The correct answer is, it depends. Software requirements training should fit with the type of project management used by your organization.

One type of training you don't need

Many people think a software requirements engineer should thoroughly understand programming and software engineering. Obviously, you should know something about the software engineering discipline, but knowing too much can destroy your ability to write good requirements. This happens for two reasons.

First, good requirements should ignore the technology (such as which platform or language is used). This is because requirements should not dictate the solution; they should only define the problem to be solved. Devoting too much study to the technology will bias a requirements analyst toward particular solutions. This makes consideration of alternate solutions more difficult for the design engineers.

Second, requirements elicitation is an art as much as a discipline. Managing stakeholders, conducting meetings, choosing elicitation methods, and choosing methods for representing information require strong skills in psychology and communication. Putting all your energy into learning programming languages and tricks will cost you on the human side. It would be as great a mistake as putting all your energy into market research. You need to know enough about programming to win the respect of the designers and to communicate with them, but your job is to build a bridge between the customer and the designer.

What should I wear? Well... where are you going?

Organizations that work with large systems that integrate multiple technologies tend to follow traditional Project Management and Systems Engineering methods. They use some variation of the Waterfall model, such as the V model.

For a high-level understanding of Systems Engineering requirements methods, I recommend starting with INCOSE's (International Council on Systems Engineering) Systems Engineering Body of Knowledge (SEBOK) and using the SEBOK as a guide to subjects for study. Also consider studying Model-Based Systems Engineering, one subset of traditional methods, and SysML, the modeling language used for MBSE.

Organizations that work primarily with software tend to follow Agile project management methods. In Agile environments, requirements engineers tend to go by the title Business Analyst. I recommend starting with the IIBA's (International Institute for Business Analysis) Business Analysis Body of Knowledge (BABOK) and using the BABOK as a guide to subjects for study.

Agile is a set of principles and not an actual method. I have asked for a recommendation for a book that describes the different methods (such as Scrum and Kanban) but have been told no such book exists; for each Agile method, you need to find a different book.

The requirements methods differ considerably between traditional and Agile. Traditional methods nail down requirements and then negotiate schedule and cost. Agile nails down schedule and cost and then negotiates, prioritizes, re-prioritizes, and drops requirements.

The two methods do share some of the same tools. I suggest studying Unified Modeling Language (UML). UML is not a language, but a set of graphical methods for defining requirements. The most commonly recommended book on software requirements is Software Requirements, 3rd edition, by Karl E Wiegers and Joy Beatty.

Communicating the Organization's Direction: The Missing Ingredient

The average worker could not tell you the vision of the employer.

To some degree, the average worker can perform just fine without knowing the mission and goals of the business. However, knowing the purpose of the work can guide decisions made in the course of the work. Perhaps more importantly, having a known, defined purpose can motivate the worker by providing a roadmap to the work's contribution. It provides a personal connection to the work and to the company. This, in turn, improves performance and retention.

Leadership can improve overall performance by communicating the vision, mission, and goals of the business, as well as the specific objectives of each project. (To cut down on wordiness, I'm going to combine all of those messages and call them the "direction" of the business.)

This topic could take up a whole book, but I will address a portion that I think leaders tend to forget. The specific methods and tools used will vary during the lifecycle of a project. For that reason, I would recommend organizing a more complete description of the topic around process groups or project phases:

• Project selection
• Project initiation
• Project planning
• Project execution
• Project monitoring and control
• Project closure

Defining the direction is part of creating the business plan. Any responsible business owner will create most of those materials and update them regularly. From there, communicating the direction requires breaking each section into a PowerPoint presentation, asking lower-level leadership to give it visibility, putting it to work in the organization, and setting up systems of accountability.

Businesses commonly forget to ensure that the elements of the business direction flow down to projects. Leaders present and promote the direction, but they also need to communicate it through actions that create the processes and provide the tools for carrying out the direction and controlling its implementation.

Just as the business needs to continuously review and refine the direction, the projects need to ensure alignment with the business direction. For example, many project managers set the contract as the highest level of requirements. However, many decisions made within a project depend on the business direction.

Leadership can take one step to communicate business direction by empowering Project Scope Management. They can do this by making available a good Requirements Management System (a tool such as DOORS or CORE). The project managers should then include the business direction's documentation as the top level of each project's requirements. During the project lifecycle, the project can ensure that decisions support the business direction and all requirements trace to the business direction.

Many leaders focus on communicating business direction through presentation. However, they must also communicate it through action. Obviously, actions include specific soft-skill behaviors such as demonstrating the importance of meetings by prompt attendance. But they must invest in resources that empower their teams to use direction as a tool and to use it as the measuring stick of performance.

Agile, Waterfall, and PMI Project Differences

I've been asking about the differences between Agile projects and traditional project management.  Many explanations err by answering the question only from a software or Information Systems perspective.  While Agile primarily appears in the software industry, the different approaches appear in many industries and product areas.

Since the Project Management Institute (PMI) offers both Project Management Professional (PMP)^® and PMI Agile Certified Practitioner (PMI-ACP)^® certifications, it would seem that Agile contrasts against traditional project management. 

However, it would be more instructive to contrast the Agile approach against the "traditional waterfall approach" of Systems Engineering.  (Refer to the International Counsel on Systems Engineering (INCOSE) for details.)

Agile uses a highly iterative approach that works better when requirements are vague and must be defined over the course of the project.  It is more appropriate for, as an example, the next set of security updates to Windows or the next year's model of the Ford Mustang.

The waterfall approach assumes progressive or phased elaboration of a fixed set of requirements that can be defined, validated, and turned into a design architecture or solution, from top to bottom.

However, Agile methods can still be used for portions of the system, particularly peripheral functions of the software. It is more appropriate for, as an example, the core of MS Project 2015 or a new hybrid squirrel-electric vehicle.

 

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

The Best Project Management Software

Project management covers many knowledge areas. Developers approach PM software functionality from the perspective of a particular discipline or PM knowledge area. The approaches usually focus on a narrow selection of the following needs:

• Requirements
• Software Development Life Cycle (SDLC)
• Agile methods
• Model Based Systems Engineering (MBSE)
• General verification/validation
• Software test management
• Software test management with scripting
• Issue and change management
• Product definition from a market research angle
• Scheduling
• Cost management
• Resource management
• Project communications
• Scope and requirements definition
• Quality management
• Configuration management

As a result, all the solutions I have looked at work for only a small portion of project management. For example, MS Project would be useless for requirements management, and DOORS would be useless for project scheduling.

 

Some developers stress integration of their products with other products -- preferably their own. For example, Rational (specializing in SDLC) bought DOORS and worked on integrating the two product lines. Then IBM bought Rational and expanded the integration effort to include other IBM products.

 

Implementing many PM software products and then tailoring them to the organization's needs can require permanent, trained resources. Integrating several products can take years, even in large organizations.

 

With the current state, I believe any attempt at a total PM solution will require a very large initial effort, significant support to maintain the solution, and an acceptance that some interfaces between PM processes just have to be done by hand.

 

Therefore, to answer the question, "What is the best software/tool for end-to-end Project Management?" you need to prioritize the areas of PM because no product addresses the end-to-end needs -- or at least, the top-to-bottom needs.

The Verification Cross-reference Matrix (VCRM)

Background

After defining and organizing requirements, managers need to track compliance.  This post describes a method used in engineering, but the method helps with any kind of project. The Verification Cross-reference Matrix (VCRM) addresses, or puts you on the path to addressing, many needs.

1. Requirements, as documented through surveys, interviews, analyses, contracts, Statements of Work, standards, or regulations often mix requirements with preferences and background information. Before you begin work, you need to isolate the essential information to gain approval of mutual understanding between customers and the planners or designers.
2. To determine or reflect the steps of the service or the components of a product (for example, in a Work Breakdown Structure), you need to organize requirements.
3. Before starting work, you need the team's agreement that the requirements make sense. For example, are they SMART -- Specific, Measurable, Achievable, Realistic, and Timely? (There are many variations on SMART, and it is only the beginning of the types of tests one can apply to requirements. For example, is the requirement written in active voice? Does each sentence have exactly one requirement? Is each requirement verifiable?)
4. The planners or designers need the requirements in a format that allows them to check off each requirement as they put it into effect in the plan, solution architecture, or detailed design.
5. Risk analysts need a list of requirements for early what-if analysis.
6. Test engineers need to identify parameters that will require measurement. They will need to add requirements to build measuring points and measuring devices into the system, or they will need to obtain test or monitoring equipment.
7. Verification requires planning the conduct of testing so that it occurs in a logical order and in coordination with other processes such as project phases, start-up, or burn-in.
8. Validation and customer acceptance require relating the results of verification back to the original requirements as evidence of compliance with the terms of the contract and fulfillment of the customer's needs.

This post provides a summary of traditional methods that support the above needs.  Each topic above could lead to another post, or even books. When exploring this area, one should consider another tangential topic, requirements traceability. Traceability allows creating threads showing linkage of the details to the general requirements. This allows management to

• identify every detail that may be affected when a more general requirement changes
• prevent creation of details that the general requirements do not authorize
• ensure that the details fulfill every general requirement
• re-use portions of the product's or service's organization in future projects for cost and schedule estimating and for planning or design.

The VCRM

A VCRM lists the requirements of a specification and identifies the method(s) for verifying them. The details included in a VCRM vary with the customer, the phase of the contract, the nature of the contract, and the relationships within the contract.

Simple VCRMs such as the one used by NASA in figure 1 list requirements and the appropriate quality control methods for each requirement. This would more properly be called a “Requirements Verification Matrix.” Detailed VCRMs may include considerably more, such as test ownership, verification requirements, and verification results.

Figure 1. Simple VCRM from a NASA specification. (Click for larger version.)

The QC methods normally include Inspection, Analysis, Demonstration, and Test (IADT).

• Inspection includes qualitative observation. "The fruit basket shall include three Granny Smith apples." (You don't need to run DNA tests to verify that.)
• Analysis includes computation or comparison to historical or experimental data.
• Computation: One might have to calculate the power of munitions, since using them destroys them.
• Comparison/Similarity: Since Project A used Widgets, Project B can re-use the historical data to show that the Widgets meet its requirements.
• Modeling and simulation: We have all seen photos and videos of smoke streaming over the wings of model airplanes or cars in wind tunnels. Did you know that scientists can run computerized simulations of galaxies colliding? They get the results a lot quicker than when they wait around billions of years to see what happens.
• Demonstration verifies performance of a function that does not require qualitative measurement.
• Test verifies that a function executes within specified parameters.

Variations

Figure 2 shows an example VCRM from the Department of Transportation that includes the complete text of each requirement, added information about the verifications, and the party responsible for each requirement's verification.

Figure 2. Example VCRM from the DOT. (Click for larger version.)

The DOT calls what NASA used (figure 1), a Requirements Verification Matrix. The simpler table does not really cross-reference the requirements to anything else. The DOT adds part of the Test Plan (columns 4-6) before calling it a VCRM.

The DOT adds Certification of Compliance as a test method. They don’t define it, but it sounds like a type of Inspection where you inspect a certificate rather than inspecting the product. Since the contract has multiple sellers, Certification of Compliance might refer to using certificates provided by an equipment provider. For example, if the Government furnishes its own equipment for the contractor to install, it may already have verified the equipment’s compliance. Other examples would include calibration certificates or certifications by independent testing labs.

Figure 3 shows an example of a procurement specification that allocates verifications to contractual phases and cross-references performance requirements to verification requirements. Figure 3A shows the table and figure 3B shows verification requirements.

Figure 3A. VCRM used by U.S. Army Corps of Engineers. (Click for larger version.)

Figure 3B. Verification requirements used by U.S. Army Corps of Engineers. (Click for larger version.)

Figure 4 includes a “VCRM” that documents not only the verification plan, but also the data that determines compliance. This goes beyond calling it a “VCRM.” It should, perhaps, be called a Verification Report.

Figure 4. Verification requirements used by U.S. Army Corps of Engineers. (Click for larger version.)

Forcing design and requirements engineers to identify verification methods protects both Buyer and Seller by ensuring that the requirements are verifiable. By definition, one cannot verify an unverifiable requirement. Without objective verification criteria, a Seller can falsely claim to have fulfilled the contract or a Buyer can claim the Seller did not fulfill the contract. Including VCRMs in specifications allows general agreement about requirements verification methods and prevents problems during product acceptance and at contract closure.

In the world of paper requirements documents, VCRMs occupy an appendix or the beginning of the Quality Assurance section. Each document contains its own VCRM. Simple tables contain the data. However, Requirements and Test engineering should control VCRMs centrally. The reason requires taking a tangent into requirements control.

Tools

Many projects now used a database such as DOORS to control requirements. Databases' storage tends to isolate a sentence from its context, forcing statement of each requirement explicitly and independently. The repetition is a pain, but it ensures design quality by forcing exhaustive identification of requirements and by reducing or identifying ambiguity in the scope.

At one company, a project manager employed a distributed requirements database. He allocated requirements using spreadsheets and distributed them to the various design teams. He reassembled the spreadsheets later.

During the project, multiple teams took ownership of some requirements, while nobody took ownership of others, especially when one team would try to transfer ownership of a requirement to another team. Project management had to play catch-up with ownership changes and the teams had to take corrective actions to address dropped requirements.

The lack of centralized control also resulted in the loss of rationales and lessons learned. A robust requirements database would have retained such information. Even a requirement labeled "not a requirement" would have been retained in previous baselines.

Instead, teams kept records at inconsistent levels of detail and often discarded records after deeming them irrelevant to their own efforts.

A requirements database allows you to trace up and down the layers requirements as they are decomposed. One can use Excel spreadsheets for a simple set of requirements. A larger operation needs tools such as DOORS, RTM, or a database developed in house.

Such tools allow one to verify product scope by ensuring that lower-level specifications satisfy each top-level requirement. The help prevent requirements creep by verifying the contractual authority of each bottom-level requirement. This is called traceability.

One can also take the requirements database to the next level by adding (or linking to it) a Verification layer. The Verification layer identifies the Test plan that verifies each requirement. A robust database could even contain the test documents and results.

Case Study

A friend, Jim Pannunzio, once worked on a contract for a first-of-its-kind product. Since many requirements had high risk of being unachievable, the contract provided incentive fees for accomplishing the high-risk requirements.

The company had not used the right tools, so they had not traced some successful tests to the requirements and had failed to bill the customer. This cost them money. When Jim cross-referenced the verifications to the requirements, he found a number of such requirements. Jim also found requirements that the company had failed to verify. This allowed him to suggest further verification.

By identifying untested requirements and untraced successful verifications, Jim’s attention to detail brought hundreds of thousands of dollars of added revenue to his company and turned the project from an economic failure into a success.

Conclusion

Tight integration between requirements and verification provided by a VCRM forms a vital link between design and thorough quality control, between contractual provisions and acceptance, and between the buyer’s and seller’s bank accounts.

For more information see:

Scukanec, Stephen. A Day in the Life of a Verification Requirement. Northrop Grumman. 28 January 2008. http://sstc-online.org/2009/pdfs/SJS2408.pdf
or
Scukanec, Stephen, and James van Gaasbeek. A Day in the Life of a Verification Requirement. Northrop Grumman. 24 October 2007. http://www.dtic.mil/ndia/2007systems/Wednesday/AM/Track1/5536_1004_1042.pdf

Sources:

Figure 1: Goddard Space Flight Center, Greenbelt, Maryland. National Polar-Orbiting Operational Environmental Satellite System (NPOESS) Preparatory Project (NPP), Science Data Segment Requirements Specification, GSFC 429-05-11-01. April 7, 2005. http://nppwww.gsfc.nasa.gov/PEATE/NPP_SDS_Lev3Req.doc. Downloaded 1 June 2011.

Figure 2: Office of Operations, Federal Highway Administration, Department of Transportation. Testing Programs for Transportation Management Systems: A Technical Handbook. Appendix A, Example Verification Cross Reference Matrix. June 20, 2007. http://ops.fhwa.dot.gov/publications/tptms/handbook/app_a.htm. Downloaded 1 June 2011.

Figure 3: Engineer Research And Development Center, Corps Of Engineers, U.S. Army Topographic Engineering Center, Alexandria, VA. Performance Specification: Improved
Position and Azimuth Determining System (IPADS), MIL-PRF-52955C. 8 November 2002. https://aais.ria.army.mil/AAIS/Award_web_03/DAAE2003D01500000/DAAE2002R0177/attach_exhib/spec_attachment_2.pdf. Downloaded 1 June 2011

Figure 4: Baun, Rich. GLAST Large Area Telescope: LAT Pre-Shipment Review: LAT Level Test Verification Process. Gamma-ray Large Area Space Telescope. 27 April 2006. http://www.slac.stanford.edu/exp/glast/flight/rdm/livepreship/04_Test_Verification_Process.pdf. Downloaded 1 June 2011.

Copyright 2011, 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e