CASE STUDY FOR PROJECT MANAGEMENT

REQUIREMENT MANAGEMENT

Group Members:
NIYATI KALYANPUR ~ 19 SHRUTI VIDYANAND ~ 52

Acknowledgement
I take this opportunity to express my deepest sense of gratitude and thanks to my guide Miss Pallavi Nishandar for her keen interest and timely suggestion by which it has been possible for me to complete the project well within time. I am also thankful to all the teachers and friends who made available the theoretical aspect to the subject which made my project a success. I am also thankful to Vartak College for making resources available. Last but not the least I wish to acknowledge the encouragement I received from my colleagues who helped me indirectly to complete this project work.

VidyaVardhinis
Annasaheb vartak college of Arts K.M.College of Commerce and E.S.Andrades college of Science

Certificate
Class: T.Y.B.Sc (IT) Year: 2012-2013 This is to certify that work in this Project is work of
Ms NIYATI KALYANPUR 19 Ms SHRUTI VIDYANAND 52

Has satisfactorily completed the required project for their case Study for Requirement Management and worked for Semester-6 Of the year 2012-2013 in Vartak College as laid down by Mumbai University

_______________ Head of Department

_______________ Internal Examiner

_____________ Subject Teacher

Date: / / Place: Vasai

Index Page No. 6 7 8 9 10 11 12 14 20 21 22 23 24 25 28 29

Introduction What is business requirement? Purpose of Good Requirements Methodologies and Approach What are good Business Requirements? Types of Requirements Requirements Traceability Matrix (RTM) Requirements Management Process Managing Requirements Requirements Management Skills Top 10 Reasons for Requirements Management Requirement Management Tools Top-5 Benefits of Requirements Management Tools

Topic

Remark

Accompa
Conclusion References

Introduction
The purpose of requirements management is to ensure an organization's documents, verify and meet the needs and expectations of its customers and internal or external stakeholders. Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these. The traceability thus established is used in managing requirements to report back fulfillment of company and stakeholder interests, in terms of compliance, completeness, coverage and consistency. Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes. Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of.

What is business requirement?

The terms Business Requirement, User Requirement, Functional Requirement and just plain Requirement are generally used interchangeably. A requirement is dened as a condition or capability to which a system must conform. It can be any of the following: A capability needed by a customer or user to solve a problem or achieve an objective A capability that must be met or possessed by a system to satisfy a contract, standard, specication, regulation, or other formally imposed document A restriction imposed by a stakeholder. Most Requirements that are being expressed or written are not real business requirements. They can contain other information such as system specifications, planning information, background information and generally useless information. The job of Business Analysts and Requirements Engineers, is to make sure only Pure Business Requirements are being captured and recorded.

Purpose of Good Requirements

Many executives fail to understand the purpose of writing and documenting good requirements. As a result, projects end up being late, over budget, and not delivering what the user wanted. The purpose of writing good requirements is:

To set the scope for the project To show what the stakeholders want To give stakeholders chance to say what they want To represent different viewpoints To check the design To measure progress To accept products against precise criteria ,

Methodologies and Approach

Requirements are developed using a structure approach called Requirements Management. Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform. The Requirements Management Process generally consists of 4 steps. These steps are typically known as 1) Gathering; 2) Analyzing; 3) Organizing; and 4) Validating. The Gathering, Analyzing, Organizing and Validating steps are considered the Analysis part of the overall System Development Lice-Cycle (SDLC) approach to software development. There is also an ongoing managing activity which ensures that the requirements are aligned with various modules and test scripts which are being developed as part of the project. The process used for managing this alignment is known as traceability and uses a Requirements Traceability Matrix. A good Requirements Definition approach can also be used to support the Project Management activities of the project.

What are good Business Requirements?

Good Requirements are written independent of the system or potential system that would be built to satisfy the need. A Good Business Requirements Structure is made up of four distinct parts: 1. 2. 3. 4. the user the result the object the qualifier

You must include all of these parts to ensure proper understanding of the requirement. Sure, the solution or system specification may very well be to send an email, but alternatives should be identified and valuated. For example, one alternative might be to fax the customer the order confirmation. This may be the best cost effective solution for the amount of orders received through this channel. Keeping your requirement at the business level will ensure a better approach to problem solving and ensuring determining the right solution. Good Business Requirements must contain one and only one requirement. Do not create requirement statements which contain Multiple Requirements. Multiple Requirement statements cause too much confusion and are hard to measure. Every effort must be made to ensure only one single need is expressed in each requirement statement.

10

Types of Requirements
Functional Requirement (Function)
A Functional Requirement is a requirement that, when satisfied, will allow the user to perform some kind of function. For example: The customer must place an order within two minutes of registering For the most part, when people are talking about Business Requirements, they are referring to Functional Requirements which are generally referred to as requirements. Functional Requirements have the following characteristics:

uses simple language not ambiguous contains only one point specific to one type of user is qualified describes what and not how

Non-Functional Requirement
A Non-Functional Requirement is usually some form of constraint or restriction that must be considered when designing the solution. For example: The customer must be able to access their account 24 hours a day, seven days a week. For the most part when people are talking about Constraints, they are referring to NonFunctional Requirements. Non-Functional Requirements have the same following characteristics:

uses simple language not ambiguous contains only one point specific to one type of user is qualified describes what and not how

11

Requirements Traceability Matrix (RTM)

The Requirements Traceability Matrix (RTM) captures the complete user and system requirements for the system, or a portion of the system. The RTM captures all requirements and their traceability in a single document, and is a mandatory deliverable at the conclusion of the lifecycle. The RTM is used to record the relationship of the requirements to the design, development, testing and release of the software as the requirements are allocated to a specific release of the software. Changes to the requirements are also recorded and tracked in the RTM. The RTM is maintained throughout the lifecycle of the release, and is reviewed and baselined at the end of the release. It is very useful document to track Time, Change Management and Risk Management in the Software Development. Here I am providing the sample template of Requirement Traceability Matrix, which gives detailed idea of the importance of RTM in SDLC. The RTM Template shows the Mapping between the actual Requirement and User Requirement/System Requirement. Any changes that happens after the system has been built we can trace the impact of the change on the Application through RTM Matrix. This is also the mapping between actual Requirement and Design Specification. This helps us in tracing the changes that may happen with respect to the Design Document during the Development process of the application. Here we will give specific Document unique ID, which is associated with that particular requirement to easily trace that particular document. In any case, if you want to change the Requirement in future then you can use the RTM to make the respective changes and you can easily judge how many associated test scripts will be changing.

12

The following is the sample Template of Requirements Traceability Matrix.

13

Requirements Management Process

The Requirements Management Process is a structured approach for the capture, organization and management of Business Requirements. These steps are commonly known as the Analysis phase of the Systems Development Life-Cycle (SDLC). The Requirements Management Process typically consists of the following four steps:
1. 2. 3. 4. 5.

Gathering Analyzing Organizing Approving Controlling

1. Gathering is those activities associated with the collection of the business requirements

from the various sources including document and stakeholders.

2.

Analyzing is those activities associated with the negotiation and determination of what the requirements actually mean and which stakeholders requirements take priority. It determines which requirements should be addressed in the project.

3. Organizing is the documentation and organizing of the requirements. Normally

requirements can be classified into functional and non-functional requirements. The document created is the User Requirements Document.
4. Approving is the confirmation and signoff from the stakeholders that these are the

requirements they want to be addressed in the project.

5. Controlling is a valuable activity that aligns the Requirements Management activities

with other Project Management activities

14

1. Controlling requirements
To be able to Control Requirements you must first have a plan. Your Requirements Management plan is part of the overall Project Plan. Requirements Control includes but it not limited to: 1. Project Scope: This section explains the scope of the project and what areas will be affected during the project 2. Activities: What are the activities being used in each of the Requirements Management steps. Will requirements management training be supplied? What methodologies will be used? What gathering techniques will be used (workshops, interviews, documents, etc.)? Who will attend the various workshops? Who will be interviewed? What documents will be reviewed? How will the requirements be analyzed? Will models be used? Or perhaps Use Cases? What software will be used to manage the requirements? What deliverables will be produced? Who will be responsible for signing and approving the requirements document? Will a meeting or workshop be held for the approval process? How will changes or additions be handled? How will all this activity be communicated? 3. Resources: This section will describe what resources need to be allocated to Requirements Management. Will there be enough funding in place to support the activities described in the Activity Section? Will the right people be available at the right time? Is there a financial commitment as well as a time commitment? Do you require access to existing systems and their documentation? Do we need special space available such as meeting rooms? Etc.?

4. Schedules: How long will this activity take place? When are people available? Are there time constraints such as holidays or regulatory deadlines (e.g.January 1, 2000). When are people taking their holidays? 5. Stakeholders: Who will be affected by this project? What are their concerns or problems? What would they like to see fixed? Are they willing to participate in the various activities and what are their schedules?

15

2. Gathering Requirements
How do you go about gathering requirements? So where is it that you go to get all these Business Requirements you might ask? There are several sources for Business Requirements. Key sources are listed here but are not in any particular order:

Stakeholders Documentation Corporate Goals Existing systems Subject Matter Experts

There are various techniques which can be used for gathering Requirements. Some of these techniques help engage the participants in a meaningful discussion which gets their thoughts flowing and paints a better picture for what the stakeholder is looking for.

Workshops reading documents Interviews Prototypes Market Analysis Observations The focus of the Requirements Gathering activity is to capture all the requirements. It is not to ensure that the requirements are being expressed properly nor is it to resolve which requirements takes priority over other requirements. The Analysis will take care of that. Just capture all the raw requirements you can and you will weed through them later.

16

3. Analyzing Requirements
Analyzing requirements is one of the most critical activities of the Requirements Management Process. The objective of this activity is to make sure you have well formed, well written business requirements that everyone has agreed to. Steps that should be done in the Analyzing Requirements activity are: 1. 2. 3. 4. Writing Classification Prioritization Negotiation

1. Writing During the Gathering Requirements activity you managed to collect a bunch of raw requirements. A good Business Requirement is defined as a true business need and must be independent of any system. It is composed of four distinct parts: 1) the user; 2) the capability; 3) the object; and 4) the qualifier. It expresses a single business need. 2. Classification Requirements can be classified as either functional or non-functional. Functional requirements can be further classified into subject domains such as shipping, ordering, billing, etc. Non-Functional requirements can be further classified into such categories as security, performance, availability, etc. 3. Prioritization Analyzing Requirements should also prioritize the requirements based on some meaningful scale. A scale such as the following should be used: Mandatory Desirable Optional This scale will help determine which requirements can be eliminated if it is decided to reduce functionality due to cost constraints when designing the solution. 4. Negotiation During your Requirements Gathering activity you received many different requirements from many different stakeholders. Some of these requirements are contradictory and need to be resolved.In the Analyzing Requirements activity you must now look for ways to resolve any conflicting requirements. This requires special negotiation techniques. The objective of the negotiation is to determine the overriding requirements which best represents the business needs of the organization.
17

4. Organize Requirements
The main purpose of the Organize Requirements activity is to organize the requirements and to produce a User Requirements document. Reference Number Every Business Requirement would have now been classified into various categories. To better organize requirements we must now assign a reference number that the requirement will be assigned for the life of the project. (e.g. FR-0010, NR-0025). Requirement reference numbers will assist in aligning future development artifacts (functional designs, modules, test scripts, etc.) to the original requirements. Business Requirements Document The main purpose of this document is to facilitate the presentation and signoff of the Business Requirements that have been captured and agreed upon. The Business Requirements Document also describes the overall Business objectives and goals. Here is a sample format that could be used. 1. 2. 3. 4. 5. Introduction Scope Business Goals Project Constraints Functional Requirement 1. FR-0010 Functional Requirement 2. FR-0020 Functional Requirement 3. FR-xxxx 6. Non-Functional Requirement 1. NF-0010 Non-Functional Requirement 2. NF-0020 Non-Functional Requirement 3. NF-xxxx Functions Appendices 1. Models 2. Definitions

18

5. Approving Requirements
The last activity in defining requirements is approving requirements. You must make sure that all the requirements are approved and documented and that these requirements define what it is the stakeholders want. The main objective of this step is to make sure that ALL the stakeholders agree on what business requirements the project is going to address and what is in scope for the project. This process should include the following types of people: 1. Reviewers people reviewing for content and structure and providing feedback. They are your subject matter experts, the users, quality assurance, etc. 2. Approvers people who are formally agreeing to this document as the scope for the project. These are typically people who have the authority to accept this change and to allocate resources to the project. This group should include the business owner(s), senior management, project manager, etc. 3. Project Team These are the people who will accept this document as their problem definition statement. The group should include your programmers, architects, etc. This is for information only to allow them to start thinking about the project. The actual activity of reviewing and approving the requirements needs to be planned and should contain the following steps: 1. 2. 3. 4. 5. 6. 7. Determine approver distribution list. Distribute Business Requirements document to distribution list. Solicit feedback and document responses. Incorporate specific responses that do not impact other stakeholders. Plan and schedule Requirements Approving Workshop. Conduct Business Requirements Approving Workshop. Address all responses received from Step 3 above.

This is one activity which cannot be overlooked or hurried through. Take your time and make sure that everyone thoroughly understands each requirement. Review each response from Step 3 above. Baseline Once all the requirements have been reviewed and signed off they must be baselined. Baselining is the first official version of the Business Requirements. Any changed to this document, after it has been baselined, will require a change request and, possibly, more resources.

19

Managing Requirements
Managing Requirements is the activity that follows the intensive work that goes into the defining requirements part of the Requirements Management Process. With approved Business Requirements in hand, we are able to proceed with the process of managing the Requirements, which involves the six key phases of the Systems Development Life Cycle (SDLC): Analyze - project requirements are defined and evaluated for feasibility Design - design the specific details of the product or service Build - the first version of the product or service is produced Test - the validation of the product or service Deploy - installation and activation of the approved product or service Support - ongoing monitoring and maintenance of the product or service This manage requirements activity ensures that the requirements are aligned with various modules and the test scripts that are developed as part of the project. The end result of manage requirements is the completion of a project such as the release of a new product or the implementation of a new service.

20

Requirements Management Skills

Six essential management skills: Analyze the problem. Understand the user needs. Define the system. Manage the scope of the system. Refine the system definition Manage the changing requirements

21

Top 10 Reasons for Requirements Management

1.Increase project management effectiveness and cross-functional collaboration capabilities. By identifying and agreeing on requirements, your team will be taking the first step towards operational excellence. 2. Manage projects more accurately i.e. controlling costs, meeting project due dates, and fending off scope creep. 3. Ensure that detailed tasks are never lost through the cracks in organization no matter how broad or deep the requirements may range. 4. Assign responsibility, accountability, tasks, and even plan segregation of duties. 5. Ensure that service and contractual relationships are clearly defined. Originally defined terms and conditions including obligation dates and milestones can be managed more successfully. 6. Ensure that stakeholders fully understand project scope and complexity across the entire set of requirements that defines a projects work breakdown structure (i.e. a set of work tasks). 7. The practice of requirements management is an ideal way to integrate processes. By identifying process-specific requirements you will be able to attack the major issues associated with process hand-offs (i.e. where one process ends and another begins). 8. The practice of requirements management allows your team to create a baseline; a defined set of requirements that have been agreed upon. 9. Requirements management discipline helps you to deal with business and technical change. Each requirement can undergo a formal review before it is accepted into a current project, or scheduled for a future time period. This allows you to stay focused on a current baseline. 10. The practice of requirements management allows users to understand the importance of requirements traceability. This enables users to conduct business impact and traceability impact assessments. This is a critical aspect of managing GRC projects and programs successfully.

22

Requirement Management Tools

1. Enterprise-level Requirements Management Tools These tools are primarily targeted at large, enterprise-level implementations. They are usually very expensive but are also loaded with features for enterprises.

IBM Rational DOORS Borland Caliber

Mid-market Requirements Management Tools These tools provide a nice balance between the feature set of enterprise-level tools listed above and ease-of-use of entry-level tools listed below.

Accompa Jama

Entry-level Requirements Management Tools These tools are affordable and can be used to manage requirements in a structured fashion especially at smaller organizations. There is one caveat these are notfocused on requirements, but rather on issues/bugs.

Atlassian JIRA FogBugz

Free, Open Source Requirements Management Tools Are you interested in using open source requirements management tool installed on your own servers? Check out the following:

aNimble

23

Top-5 Benefits of Requirements Management Tools

Here are 5 key benefits you can achieve by using an RM tool instead of just a general-purpose tool to manage your requirements. 1. Structured Requirements: Requirements management tools enable you to gather structured requirements. This basically means you can define attributes youd like to track for each requirement (such as Requestor, Needed Date, Owner, etc) and then make sure each requirement has those attributes. 2. Save Time: A good requirements management tool can save you a ton of time when it comes to managing your requirements, as they automate a lot of requirements management tasks like creating requirements documents. 3. Less Stress: Most PMs/BAs/Engineers whore responsible for gathering and/or tracking requirements will confess that this task is pretty stressful due to the inherently chaotic nature of the process. A good RM tool can eliminate a lot of the unnecessary stress associated with this process. 4. Workflow & Best Practices: Good requirements management software tools have built-in workflow and best practices for a lot of tasks related to requirements management. This will help you make your products and projects more successful. 5. Easy to Collaborate: A good requirements management tool will enable you to collaborate with your internal and external stakeholders efficiently & effectively. Generalpurpose tools are not very effective due to lack of requirements-specific collaboration capabilities.

24

Accompa
Accompa is the fast-growing startup company located in Silicon Valley - in Santa Clara, California (United States). Mission: To help customers build more successful products, more efficiently- by enabling them to continuously improve every part of their requirements management process. More than 100 companies in 4 continents - ranging from Fortune-500 companies to growing startups - rely on our software every single day to meet their requirements management needs. Here's a small sample of well-known companies who use Accompa to manage their requirements management processes in a powerful, efficient and repeatable fashion. Yamaha Cisco Adobe Hp Citrix Symantec RBS(Royal bank of Scotland) Intel Genentech They conducted an in-depth survey of companies who had been using Accompa for at least 12 months. 23 companies participated in our survey. They asked them to outline the various benefits they've gained from using Accompa to manage their requirements, and worked with them to quantify these benefits. We aggregated this data and calculated the average Return-on-Investment (ROI). Here's what we found... On Average, These Companies Achieved 17x ROI

25

Here Is How They Achieved 17x ROI

On average, Accompa users spend 28% of their time on requirements. This includes gathering, tracking, collaborating on, and managing requirements - as well as creating requirements documents.

28%

$106,000

On average, the fully-loaded annual cost of an Accompa user (Annual salary + Bonus + Benefits + Overhead). This varies with geography, and is the highest in the western U.S.

16%

Companies estimated that, on average, Accompa saved them 16% of their time spent on managing requirements - compared to their old tools such as Excel, Word or wikis.

$4,749

Annual productivity gains per user from using Accompa, averaged across all 23 companies. Calculated by multiplying the three factors above.

$278

Annual investment per user for Accompa. This is the average annual fee per user, and includes volume discounts for companies with a large number of user licenses.

17x

Return-on-Investment (ROI) achieved by companies using Accompa, on average. Calculated using the above two factors ($4,749 divided by $278).

26

To be technically correct - the actual ROI is even higher than 17x - as many companies reported other benefits in addition to productivity gains. These included benefits such as eliminating missed requirements, sharing up-to-date requirements throughout the organization, making it easier for customers to input requirements, etc... But we omitted these additional benefits so that we could: a) Uniformly aggregate the results across all 23 companies, and b) Present the ROI to you in the simplified, clear format shown above. As a result, 17x ROI is a conservative number and only includes productivity gains.

27

Conclusion
Requirements definition and management are among the most important activities in any project, and efforts in this direction can improve and accelerate ROI. It is also the first process improvement area to focus on, based on the garbage in, garbage out rule: If the requirements are not clear, any other effort may just help you produce the wrong product faster. The first step to better requirements management is to understand the simple rules that make a requirement good. Training courses and guidance can help organizations achieve this goal. Once the basic rules are in place, organizations can further increase the quality of their requirements by implementing todays best practices. These process improvement steps are greatly aided by implementing a requirements management product that not only helps projects to manage requirements more effectively, but also helps future projects benefit from past and current lessons.

28

References
ibm.com/software/rational www.etesting.com www.accompa.com www.projectmanagement.com www.requirementsauthority.net

29