Requirements Management 

Scott Manns, IS 6840 Term Paper, Fall 2015

Submitted to Dr. Vicki Sauter, November 20, 2015

Introduction    Process    Definition    Eliciting    Analysis   

    Changes    Traceability    Validation    Challenges    

Best Practices    Software/Tools    Conclusion    References


Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders.(17) If you want your organization to be successful it means that you must deliver results. In today’s competitive business environment there is no room for failed projects and stale performance. Every company’s goal is to be successful long term and it’s becoming more and more difficult as markets are expanding globally at a much faster rate than ever before.

Requirements management keeps your team in sync with one another and provides visibility into what is actually happening and when it’s happening throughout the entire project. It’s very important for the entire team to understand what the goal of the project is and how that specific goal will be reached. It’s also important for all those involved in the project to have a mutual understanding of requirements management in order for the project to be successful. If everyone completely understands the requirements it allows for better acceptance of the goals and feedback on all the decisions being made on a specific requirement. Look at requirements as an avenue for communicating the needs and providing the validation of the projects results.

It is known that some primary reasons projects fail are because requirements are incomplete, defective, or just lack the details provided by the customer. (RF4) Incomplete requirements can also produce inaccurate products, unplanned costs, and schedule delays. Requirements must be carefully evaluated through analysis of user requirements and well documented to better understand the client’s needs. It’s important to remember that a requirement must capture what needs to be produced and not how to produce it. (Vicki Sauter)


   Requirements Management Process

In order for requirements management to be effective you must establish and create an agreement with the customer on requirement changes throughout the project. The first is requirements development, which is the process of identifying and creating requirements based on the user inputs and analysis.  I found many different outlines when looking for an industry standard requirements management process but all still focused on the main topics. We will discuss those steps that are most crucial when defining the requirements management process. 


 Requirements Management Definition

This lays the foundation for the end product and provides a view of the intended solution. It also provides the baseline for the design, testing and user acceptance. The practice of requirements definition is typically performed in the planning phase of the project right before elicitation occurs. It ensure the project meets objectives, deadlines, time constraints, and cost. 
These are identified by asking questions like:
        •  What problem are we trying to resolve?
        •  What current and new resources do we need to solve the identified problem?
        •  Do your current processes provides a solution that doesn’t fit your short or long term needs?
After this point in the project the business analyst now collects and documents the final requirements.
"Requirements management can be simplified if initial requirements definitions are captured in a database-based tool to enable collaborative review… traceability and versioning/change control”   Matt Light, Research Director, Gartner  (6)

 Eliciting Requirements
        Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as
"requirement gathering". (17)
During a normal requirements elicitation effort, it is likely that inputs will be received from numerous sources. A team member begins taking the customers’ business needs and turns them into actual requirements through the elicitation process. There are multiple meetings with clients, subject matter experts, end-users of the current system, and many other stakeholders to begin discussion about the projects goals. One early source of risk is the misunderstanding between users and developers of what the requirement actually is. Elicitation meetings require a lot of interviewing and meeting management skills in order to gather the information needed. It’s a good practice to allocate sufficient time for gathering requirements.
        When starting the elicitation process it’s important to find out if there are any existing systems with the organization that may be similar to the one that is being requested. These systems that are already in place can be studied and can potentially generate a new ideas on how the new solution should work. Another way to get a head start on elicitation process is studying the current standard software solutions that already exist in the market.

The analysts who perform the elicitation must be able to manage all stakeholders involved and not focus just on one specific group. It’s key that all parties’ views and interests be acknowledged and considered in fairness.  It’s important that analysts be curious and open minded in hopes to leading to fresh ideas and new perspectives. Analysts should never be afraid to ask “why” if they are concerned with a customer’s requirement.
        Some important skills needed for effective requirements is active listening, analyst  must be able to clearly articulate requirements, and also possess ability to align them with the projects goal. The source of every requirement is typically from the expert so it’s important that the analysts have an open mind and willingness to learn and understand from them. Another potential factor in requirements elicitation is the politics involved. I came across an article that really provided good detail into the truth behind what drives certain requirements and politics is certainly one of them. Even though analysts might not agree, it’s important to understand that analysts shouldn’t place certain stakeholders over others as it might lead to requirements that do not represent all parties involved. Needless to say it takes a well-rounded analyst to elicit accurate and complete requirements from a client. Remember elicitation should never come to an end until the project is complete, it should be revisited throughout each phase to ensure accuracy

 Requirements Analysis
         Requirements analysis is an important phase and can be used to identify key stakeholders. Creating a list of key stakeholders ensures their needs are being considered in the risk assessment process.(3)  If the client's requirements are not properly gathered and defined according to the information provided by all stakeholders then the rest of the project is now off track when trying to arrive at a solution. Requirements define capabilities that a system or a component needs to reach a solution to a defined problem. They can be divided into two categories, functional and nonfunctional. Functional requirements detail what a system should perform when a specific action is taken.  Nonfunctional requirements are the performance and system constraints that affect development. It’s important when analyzing requirements that we reduce uncertainty early on in the project. A possible suggestion to accomplish this is working backwards on the requirement while considering the exact conditions that created the uncertainty.

Managing Requirement Changes
        Uncontrolled changes can cause many different problem such as additional rework, lack of first time quality, unpredictable schedules deviations and cost issues. Following a change process can make requirement changes very easy to deal with. A requirements change process must be able to propose, analyze, approve, and implement any changes within a requirement during any part of the project. It’s also important to include an impact analysis study on what the change results might be. This allows for better understanding of the requested change and improved planning for all phases that will be impacted.  All change requests must follow a certain process that has been created or this effort will fail. Requirement changes may even sometimes require renegotiating project commitments such as time, budgets, and resources. This is where it’s important to have management buy in on the entire requirements management process.

Traceability (Recording)
        Tracing allows for someone to manage the entire life of a requirement throughout the project.  It is important to understand how traceability helps ensure accurate delivery of clients’ needs and expectations.  Tracing is more closely related to systems development and is a discipline within requirements management that can add a lot of value to a project. Traceability improves the scope management within the project and could potentially prevent you from overseeing an identified requirement. Sometimes requirements can be missed and it can lead to huge cost increases if it’s implemented late in a project and can also potentially cause huge delays. Traceability also provides the ability to track the priority of all requirements and their changes.
A study showed that 89% of initial requirements from project kick-off actually make it into the final product.(14)  It is important to note that traceability can be difficult to implement without the proper tools.  If you do not have the right resources it can lead to cost overruns and its ends up not being worth the benefit as originally assumed. Some potential best practices for traceability include connecting test cases to the actual requirements, relating system requirements to their stakeholder’s requirements and making sure your low level requirements can relate to the high level requirements so you don’t cause any delays during implementation. In a lot of industries traceability isn’t a practice anymore it’s more of a standard operating procedure and to some it might even be a mandate. Please note that it’s important to trace your requirements into all phases such as design, coding and testing phases of the project. By doing so you are eliminating a lot of risk!

        According to a Project Management Institute study that involved over 2000 practitioners, its stated organizations that use a formal validation process see significant improvement in project outcomes.   “We gather all the requirements and evaluate the project scope to understand the mutual implications and validate project requirements.”  Roberta Miglioranza, PMP,  Rio de Janeiro, Brazil
It’s very interesting to see how much more successful projects are when implementing validation process properly.


        Like any and all project process challenges will be encountered and it’s important they are identified and documented.  A big challenge for a lot of organizations is getting upper level management and executive leadership to support a RM process. Another few challenges that are encountered when creating a RM process is that end users fail to use many of the system's capabilities, or aren’t using them as they were intended for, or don’t even use the system at all. Another big challenge is traceability or lack thereof within the requirements gathering.  A study done by PTC showed that only 1% of survey respondents indicate that requirements traceability has no impact. When 99% of your responders agree that this is a crucial step, it must be acknowledged by leadership.
Check out the interesting graphic below from a survey done by Standish Report. 


        There are many different reason that projects get cancelled and it’s know that poor requirements management practices are consistently in the top 5, along with poor business alignment and strategy changes.  Many sources also cited management and technical reason why projects failed. Another big challenge is traceability and the success of tracking it. That is why a larger project should consider a RM tool to manage this difficult task. Change is inevitable so it’s a good idea to be prepared to manage that change.  (21)


spree1  Best Practices
        Best practices help create a standard operating procedure that ultimately leads to better a requirements management system.  It allows you to create a change control process that manages the entire life of any requirement. It’s also provides the option for a version control process for the entire documentation of any given requirement.
Some potential best practices for requirements management is listed below:
1. Create a RM standard/baseline that your organization follows
        a. Management approved RM process for all projects
2. Implement a version control process for all documentation
        a. all documentation is accurate and up to date
        b. restrict access to authorized users
3. Create a change control process
4. Hold peer reviews to ensure accuracy
5. Avoid terms that aren’t fully understood
6. Create workshops to educate stakeholders on requirements
7. Utilize a requirements management tool ( see information below on RM Tools)

fdfsdaf  RM Tools/ Software
        Garnter estimates that over 80% of business analysts use Microsoft Office to define requirements. Word can be used for text documents, excel can handle the large data sets, vizio is used for diagraming and visual models and PPT for presentations and flow charts. Most companies that engage in large projects start out by tracking their requirements by utilizing the Microsoft office tools but eventually end up realizing that they need to transition to a more flexible management software. Utilizing the Office suite might seem like a great idea from a cost side but it could end up becoming insufficient for the complex IT needs.  As projects become larger and more complex Microsoft Office is shown to be very inadequate in meeting the needs of the business when it comes to requirements management.  RM tools offer version tracking, requirement history, and most importantly the automatic tracking of changes at any point in the project. It’s important to understand that some RM tools have additional costs such as setup fees, supports fees, and even necessary training costs. Every project manager should weigh the pros and cons of the RM tool based on the size of the project to determine if it is needed or the basic MS office application will suffice. Today most requirements management tools are available via the cloud which makes scalability an important determining factor for some companies. Please review the video below to get a good idea of how helpful an RM software tool like IBM  DOORS can be.

fdsadfdsf  Conclusion
        Implementing a requirements management process leads to better results and is crucial to a projects overall success.  However, it’s important to create a standard requirements management process in your organization in its efforts to produce consistent and high quality results.
CIO Magazine recently published a report that stated as many as “ 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure – bigger than bad technology, missed deadlines or change management fiascoes.” (6)
         It’s also key that top level management and executive are aware of positive impacts a requirements management process can have within an organization. PMI’s survey provides a great statistic on that key item below. I leave you with a quote that I believe speaks directly to the importance of a requirements management standard process for every organization.
“In my experience, people have been spending a lot of time on titles and terminology, and have lost sight of the important work that drives outcomes. We need to put titles and terminology to the side, and instead focus on the activities that contribute to the success of projects and programs. Let’s pay attention to what really matters, and make some substantial improvements.” -- Mark A. Langley, President and CEO, Project Management Institute


Regardless of the process your team uses to gather manage requirements, this process is key to the development of any product or service. If the requirements management process is implement successfully quality results will be seen for a long time to come. 

fsadfasd  SOURCES

eferred Journals
1.    Lopez, Orlando. "Requirements Management." Journal of Validation Technology 17.2 (2011): 78-86. ProQuest. Web. 5 Oct. 2015.
2.    Cancila, Mindy. "A Comprehensive List of Management Requirements for Organizations Using Public Cloud Services." Gartner. Gartner, INC., 2 Apr. 2015. Web. 20 Nov. 2015.                                          >.
3.    Jiang, James J., et al. "The Relation of Requirements Uncertainty and Stakeholder Perception Gaps to Project Management Performance." The Journal of Systems and Software 82.5 (2009): 801.
         ProQuest.Web. 5 Oct. 2015.

4.    Zwikael, Ofer, and Oleg Tilchin. "Effective Customer Requirements Management using an Information Supply Based Model." Problems and Perspectives in Management 5.4 (2007): 50,56,91
         ProQuest. Web. 5 Oct. 2015.

5.     Githens, Gregory D. "Customer Centered Products: Creating Successful Products through Smart Requirements Management." The Journal of Product Innovation Management 18.5 (2001)
        :350. ProQuest.Web. 5 Oct. 2015.

6.     Donald J. Reifer, "Requirements Management: The Search for Nirvana", IEEE Software, vol.17, no. 3, pp. 45-47, May/June 2000, doi:10.1109/MS.2000.10022
        ECONOMY".Jun, ProQuest. Web. 5 Oct. 2015.
8.      Fiksel, Joseph, and Frederick Hayes-Roth. "Computer-Aided Requirements Management." Concurrent Engineering: Research and Applications 1.2 (1993): 83-92. ProQuest. Web. 5 Oct. 2015.
9.     Carr, Joseph J. "Requirements Engineering and Management: The Key to Designing Quality Complex Systems." The TQM Magazine 12.6 (2000): 400. ProQuest. Web. 5 Oct. 2015.
10.    Carlshamre, Pär, and Björn Regnell. "Requirements lifecycle management and release planning in market-driven requirements engineering processes." Database and Expert Systems Applications, 2000.                       Proceedings. 11th International Workshop on. IEEE, 2000.
11.    Faulk, Stuart, et al. "The Core Method for Real-Time Requirements." IEEE Software 9.5 (1992): 22-33. ProQuest. Web. 5 Oct. 2015.
12.    Ghoshal, Sumantra. "Bad Management Theories Are Destroying Good Management Practices." Academy Of Management Learning & Education 4.1 (2005): 75-91. Business Source Premier. Web. 19 Oct.

Web Sources
10.   ml&Itemid=2