Requirements Communication

Table of Contents

Requirements Communication Plan..................................................................................................2

What..............................................................................................................................................2

Why...............................................................................................................................................2

How...............................................................................................................................................3

Stakeholders..................................................................................................................................3

Sample Communication Plan Template:........................................................................................3

Classifying the Requirements............................................................................................................8

Requirements Package....................................................................................................................10

Techniques of Requirement Communication..................................................................................11

Requirements Workshop.............................................................................................................11

Structured Walkthrough..............................................................................................................13

Tools for Effective Requirements Communication..........................................................................15

References.......................................................................................................................................18

Requirements Communication

Requirements Communication Plan

What:

A brief guideline and accompanying worksheet/plan template that allows you to: Identify all those who could have an influence on your project, including stakeholders who care

about the outcome of the project, and critical information sources. Assess the nature of their impact and thus determine what types of information they need to

receive during the project. Document a plan for how, what, and how often to communicate to those influencers during the

project to ensure that expectations are met, information is exchanged, and the project meets its goals.

Why:

Projects do not take place in an isolated environment. Projects will experience positive and negative influences from a variety of sources, many of them specific people or groups. People can influence a project dramatically for the worse by refusing to commit resources, by not being available for reviews, or by failing to provide key specifications or specialized knowledge the project needs at the right time. However, if those influencers are identified, communicated with, and proactively involved by the team from the start, the project will feel the positive impact of their participation.

Therefore, during project initiation and planning it is important to consider the factors and individuals inside and outside the organization that can aid or impede the project through their attitude toward the

project and their related action (or inaction). Then the team should start working with those people, and plan for the proper communication with those influencers during the project.

How:

1. During the initiation phase of your project, create an initial Project Influencer Assessment to identify which people and groups have the potential to impact your project.

2. Immediately contact and start working with influencers who are key to the early days of your project.

3. Update the Influencer Assessment as project goals are solidified; often the details of scope, schedule, and resources will surface other project influencers.

4. As the planning phase of your project progresses, start filling in the "communication" columns of the form. This will set the team up to have proper, effective communication with the influencers throughout the project.

5. Before you exit the planning phase you should have a full-blown Project Stakeholder and Influencer Assessment and Communication Plan.

6. Keep this compact form handy during project execution to sanity check whether the project team is keeping all influencers (including key project stakeholders) informed and properly involved in reviews.

Stakeholders

Sample Communication Plan Template:

Introduction

The purpose of the Communications Management Plan is to define the communication requirements for the project and how information will be distributed. The Communications Management Plan defines the following:

Communication requirements based on roles

What information will be communicated

How the information will be communicated

When will information be distributed

Who does the communication

Who receives the communication

This Communications Management Plan sets the communications framework for this project. It will serve as a guide for communications throughout the life of the project and will be updated as communication needs change. This plan identifies and defines the roles of persons involved in this project. It also includes a communications matrix which maps the communication requirements of this project. An in-depth guide for conducting meetings details both the communications rules and how the meetings will be conducted, ensuring successful meetings. A project team directory is included to provide contact information for all stakeholders directly involved in the project.

Communications Management Approach

The Project Manager will take a proactive role in ensuring effective communications on this project. The communications requirements are documented in the Communications Matrix presented in this document. The Communications Matrix will be used as the guide for what information to communicate, who is to do the communicating, when to communicate it and to whom to communicate.

Roles

Project Sponsor

The project sponsor is the champion of the project and has authorized the project by signing the project charter. This person is responsible for the funding of the project and is ultimately responsible for its success. Since the Project Sponsor is at the executive level communications should be presented in summary format unless the Project Sponsor requests more detailed communications.

Program Manager

The Program Manager oversees the project at the portfolio level and owns most of the resources assigned to the project. The Program Manager is responsible for overall program costs and profitability as such they require more detailed communications than the Project Sponsor.

Key Stakeholders

Normally Stakeholders includes all individuals and organizations who are impacted by the project. For this project we are defining a subset of the stakeholders as Key Stakeholders. These are the stakeholders with whom we need to communicate with and are not included in the other roles defined in this section. The Key Stakeholders includes executive management with an interest in the project and key users identified for participation in the project.

Change Control Board

The Change Control Board is a designated group which is reviews technical specifications and authorizes changes within the organizations infrastructure. Technical design documents, user impact analysis and implementation strategies are typical of the types of communication this group requires.

Customer

The customer for this project is <Customer Name>. As the customer who will be accepting the final deliverable of this project they will be informed of the project status including potential impacts to the schedule for the final deliverable or the product itself.

Project Manager

The Project Manager has overall responsibility for the execution of the project. The Project Manager manages day to day resources, provides project guidance and monitors and reports on the projects metrics as defined in the Project Management Plan. As the person responsible for the execution of the project, the Project Manager is the primary communicator for the project distributing information according to this Communications Management Plan.

Project Team

The Project Team is comprised of all persons who have a role performing work on the project. The project team needs to have a clear understanding of the work to be completed and the framework in which the project is to be executed. Since the Project Team is responsible for completing the work for the project they played a key role in creating the Project Plan including defining its schedule and work packages. The Project Team requires a detailed level of communications which is achieved through day to day interactions with the Project Manager and other team members along with weekly team meetings.

Steering Committee

The Steering Committee includes management representing the departments which make up the organization. The Steering Committee provides strategic oversight for changes which impact the overall organization. The purpose of the Steering Committee is to ensure that changes within the organization are effected in such a way that it benefits the organization as a whole. The Steering Committee requires communication on matters which will change the scope of the project and its deliverables.

Technical Lead

The Technical Lead is a person on the Project Team who is designated to be responsible for ensuring that all technical aspects of the project are addressed and that the project is implemented in a technically sound manner. The Technical Lead is responsible for all technical designs, overseeing the implementation of the designs and developing as-build documentation. The Technical Lead requires close communications with the Project Manager and the Project Team.

Project Team Directory

The following table presents contact information for all persons identified in this communications management plan. The email addresses and phone numbers in this table will be used to communicate with these people.

Role Name Email PhoneProject SponsorProgram ManagerProject ManagerProject StakeholdersCustomerProject Team

Technical Lead

Communications Matrix

The following table identifies the communications requirements for this project

Communication Type

Objective of Communication

Medium Frequency

Audience Owner Deliverable

Kickoff Meeting Introduce the project team and the project. Review project objectives and management approach.

Face to Face Once

Project Sponsor

Project Team

Stakeholders

Project Manager

Agenda Meeting

Minutes

Project Team Meetings

Review status of the project with the team.

Face to Face

Conference Call

Weekly Project

Team Project Manager

Agenda Meeting

Minutes

Technical Design Meetings

Discuss and develop technical design solutions

Face to Face As

Needed

Project Technical Staff

Technical Lead

Agenda Meeting

Minutes

for the project.

Monthly Project Status Meetings

Report on the status of the project to management.

Face to Face

Conference Call

Monthly PMO Project

Manager

Project Status Reports

Report the status of the project including activities, progress, costs and issues.

EmailMonthly

Project Sponsor

Project Team

Stakeholders

PMO

Project Manager

Project Status Report

Guidelines for Meetings

Meeting AgendaMeeting Agenda will be distributed 5 business days in advance of the meeting. The Agenda should identify the presenter for each topic along with a time limit for that topic. The first item in the agenda should be a review of action items from the previous meeting.

Meeting MinutesMeeting minutes will be distributed within 2 business days following the meeting. Meeting minutes will include the status of all items from the agenda along with new action items and the Parking Lot list.

Action ItemsAction Items are recorded in both the meeting agenda and minutes. Action items will include both the action item along with the owner of the action item. Meetings will start with a review of the status of all action items from previous meetings and end with a review of all new action items resulting from the meeting. The review of the new action items will include identifying the owner for each action item.

Meeting Chair PersonThe Chair Person is responsible for distributing the meeting agenda, facilitating the meeting and distributing the meeting minutes. The Chair Person will ensure that the meeting starts and ends on time and that all presenters adhere to their allocated time frames.

Note TakerThe Note Taker is responsible for documenting the status of all meeting items, maintaining a Parking Lot item list and taking notes of anything else of importance during the meeting. The Note Taker will give a copy of their notes to the Chair Person at the end of the meeting as the Chair Person will use the notes to create the Meeting Minutes.

Time KeeperThe Time Keeper is responsible for helping the facilitator adhere to the time limits set in the meeting agenda. The Time Keeper will let the presenter know when they are approaching the end of their allocated time. Typically a quick hand signal to the presenter indicating how many minutes remain for the topic is sufficient.

Parking LotThe Parking Lot is a tool used by the facilitator to record and defer items which aren’t on the meeting agenda; however, merit further discussion at a later time or through another forum.

A parking lot record should identify an owner for the item as that person will be responsible for ensuring follow-up. The Parking Lot list is to be included in the meeting minutes.

Glossary of Communication Terminology

SPONSOR ACCEPTANCE

Approved by the Project Sponsor:

______________________________________________ Date:______________________<Project Sponsor><Project Sponsor Title>

Classifying the Requirements

The broad classification is:

Functional Requirements Non functional Requirements

More specific classification of requirements:

BUSINESS REQUIREMENTS

Business requirements identify the strategic, tactical and operational needs along with goals or objectives of the sponsoring organization. These are documented from a management perspective.

REGULATORY REQUIREMENTS

Regulatory requirements address legislative or legal requirements of an organization. They can be internal or external regulations. These are non-negotiable meaning that they Specify that the system should adhere to a law or legislation and you must elaborate on how the business system will meet the regulation.

PROCESS REQUIREMENTS

Process requirements identify what the product should do in order to fulfill the business need.These requirements can include Functional Areas. Functional areas provide a brief description of the functional area to be included in the solution. Functional area descriptions represent the mandatory process requirements of a system.

REPORTING REQUIREMENTS

Reporting requirements identify what reports the product and/or system must be able to manage.Examples include frequency of the report, run dates/times, recipients of a report, format, data source, distribution methods, storage, or other bits of information that applied to reporting.

INTERFACE / INTEGRATION REQUIREMENTS

Interface Requirements identify what information is needed to ensure that the system will communicate properly with external components. This can include things like message display, navigation links, communication interfaces, user interfaces, online forms, and interfaces with other systems.

USABILITY REQUIREMENTS

Usability requirements identify what abilities and expectations of usage experiences the product must conform to. This type of requirements can address how the graphical user interface (GUI) is designed with consideration for the different types of users and their skill levels. This can include things like online help menus, input fiends and submit buttons, save and undo buttons, etc.

TRAINING REQUIREMENTS

Training requirements identify user, help desk, and support training required for a product, or system. It can include user guides, technical manuals, certifications, level of training required, number of participants, etc.

SECURITY REQUIREMENTS

Security requirements are a subset of non-functional/supplemental requirements. Security requirements identify the security, confidentiality, integrity and privacy issues affecting access to the product or application, and protection of the data that the product or system creates or uses. This can include user roles and responsibilities, access rights, user privileges, number of user, descriptions, etc

CLIENT IMPLEMENTATION REQUIREMENTS

Client Implementation requirements identify specific impacts to the client during implementation. This can include client work load, work schedule, traveling schedule or down time.

DATA CONVERSION AND CLEANSING REQUIREMENTS

Date Conversion requirements identify the specific requirements pertaining to data conversion and cleaning. This can include the migration of employee data from the current system to the future system, Data masking, Data sanitization, etc.

AVAILABILITY REQUIREMENTS

Availability requirements identify a measurement of the planned uptime during which the system is actually available for use and fully operational. These requirements should be documented in terms of application and required availability. This can include hours of availability, critical time frames, maintenance windows, etc.FLEXIBILITY REQUIREMENTS

Requirements that measure the ease of adding new functionality to the product or system. These are the requirements that help make a product or system expand and adapt to change without having to modify the product or system.

SYSTEM CAPACITY AND SCALABILITY REQUIREMENTS

System capacity and scalability requirements identify the expected load on the system, how many users are likely to access the system concurrently, system usage and the system attributes. They can

include the average number of concurrent users, maximum number of concurrent users, average number of transactions processed per day, maximum number of transactions processed per day, etc.

PERFORMANCE REQUIREMENTS

Performance requirements identify what the product and/or system must do efficiently. This can address response time, maximum duration to execute a task, upload time, download time, and how many transactions can be processed the one time and how many users the product or system can handle.

ROBUSTNESS REQUIREMENTS

Robustness requirements identify the degree to which the product continues to function properly when confronted with invalid inputs, defects in connected software and hardware components or unexpected operating conditions. One example is the ability for the solution to recover all changes made in the file up to ten minutes prior to a system failure.

INFORMATION MANAGEMENT REQUIREMENTS

The information management requirements are meant to ensure that systems have the ability to delete records at the end of their lifecycle in compliance with the Management of information Act or other legislation. These are standard Information requirements that are required for all systems.

Requirements Package

What is the business case for requirements packages?

In our software process we strive to speed up analysis, design and development by distributing work over several teams. As we know, the larger a team becomes the more administrative overhead is incurred.  Therefore, we want to keep our teams small.

At the same time, we aim at achieving a high degree of parallelism.  For example, we might have four small teams working on use case modeling in parallel where each team is assigned a few use cases.   Undoubtedly, the question arises how we would maintain the systems requirements specification (SRS).

The SRS is a document which contains functional and non-functional requirements.   With regard to describing functional requirements we are in danger of redundancy. Our primary carrier of functional requirements are use cases which we model using UML syntax and semantics.  We would not like to run into the problem of having to maintain functional requirements in two places: in the CASE tool and the SRS (which in many cases is a Microsoft Word document).

As we are progressing with modeling we repeatedly face the problem of how to ensure consistency between CASE tool and SRS. Only the most disciplined stand a chance to succeed in maintaining consistency.

There is yet another question to solve: how can we support our highly parallel working approach?  A single SRS always becomes a bottleneck, since only one team at a time is allowed to make changes to the SRS.  They check out the document, apply their changes to it and check it back in.  Only then may some other team proceed. Surely, this inhibits progress and is not what we want.

It definitely makes more sense to split a SRS into independently manageable requirements specifications.  As the primary focus is the use case we are well advised to chain a requirements specification to a use case.  Thus, in the first instance there is a one-to-one relationship between use

case and requirements specification package.  To be exact, however, a use case is contained in a requirements specification package, since non-functional requirements have to be considered as well.In practice, each team would work on one or more requirements specification packages in an iteration.  Each team can create and maintain their requirements specification packages independently.  They are in fact the sole owners of their specification packages.By the way, splitting up a SRS into many requirements specification packages does not mean that we give up our SRS.  We can always build a SRS from its parts.

What's in a requirements package?

We want a requirements package to be a logically self-contained unit of work.  It should contain all the information necessary to completely describe a use case. How about abstract use cases? They represent requirements as well and thus we do not need to distinguish between "real" and abstract use cases.

Keeping to our definition a requirements package contains General information about the use case (purpose statement, use case owner etc.) Use case description, including pre-conditions, post-conditions, main success scenario etc. (a

CASE tool can be used to create and maintain a graphical representation of the relationship between use case and actor(s))

One or more user interfaces (if applicable) One or more dialog maps (if applicable (one dialog map for each user interface)) Business rules (as far as they apply to the use case) Test requirements for system test Non-functional requirements for the use case

Techniques of Requirement Communication

Requirements Workshop

Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each requirement, the document becomes much more useful and cost-effective.

Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You are bringing the right collection of people together, and getting them to correct and improve on their requirements document.

A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If you can define the product right the first time and cut three months off the requirements gathering, the savings could be enormous. The workshop has to be thoroughly organized to take advantage of people's time.

Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that people don't go home at night or go out separately. The example in Figure 1 shows the logic of a requirements workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques such as brainstorming.

Figure 1: Conducting Workshops

Demonstrate prototypes to stakeholders

Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can provoke them into giving good requirements information or changing their mind about existing requirements. The techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might be able to do. More requirements are likely to emerge when users see what you are suggesting.

A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here for the unwary).

This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems with the prototype! This is excellent, because each problem leads to a new requirement.

Which Technique to Apply?

Which technique to apply depends on a number of factors, such as:

Availability and location of stakeholders Development team knowledge of the problem domain Customers' and users' knowledge of the problem domain Customers' and users' knowledge of the development process and methods

If the stakeholders are not co-located or readily available, for example in the case of a product being developed for mass market, techniques such as brainstorming, interviews and workshops that require face-to-face contact with the stakeholders may be difficult or impossible.

If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the techniques described, or combination of them, may be applied. In this case, the domain and development experience of both the stakeholders and the development team are critical factors in selecting the appropriate technique.

Below figure provides a framework for determining the appropriate techniques. It defines four main categories of customer or user experience and development team experience: "Fuzzy problem", "Selling/Teaching", "Catch up", and "Mature".

Figure 2: Selection of Techniques

There is no "right answer", but these guidelines may help you decide which method to use:

Catch-up: Interviews, work in target environment Fuzzy: Brainstorming, workshops Mature: Questionnaires, workshops, prototypes Selling/Teaching: prototypes

Structured Walkthrough

A structured walkthrough is an organized procedure for a group of peers to review and discuss the technical aspects of software development work products. The major objectives of a structured walkthrough are to find errors and to improve the quality of the product. Errors typically occur as

omissions or contradictions, flaws in logic, or inconsistencies in the work product style (e.g., poorly stated requirements and inefficient code).

Structured walkthroughs should not be used to discuss solutions for the errors that are found. The basic purpose of a walkthrough is error detection, not error correction. When the walkthrough is completed, the author of the work product is responsible for taking the necessary actions to correct the errors. The author may hold private conversations with reviewers or conduct follow-up meetings todiscuss potential solutions.

Structured walkthroughs should be conducted during all stages of the system lifecycle. Walkthroughs can be conducted in various formats, with various levels of formality, and with different types of participants.

In some cases, it might be useful and expedient to include end users in walkthroughs. Management representatives do not participate in structured walkthroughs. Regardless of the variations in format and participants, the basic activity (peer review) and the major objectives (find errors and improve quality) of the structured walkthroughs remain the same.

Benefits

Structured walkthroughs provide the following benefits.

Save time and money by finding and correcting errors earlier in the lifecycle. Provide value-added input from reviewers with different technical backgrounds, experience,

and expertise. Validate and improve the related lifecycle work products. Keep the project team informed of the development progress. Provide professional growth to participants by giving them an opportunity to look at different

development methodologies and approaches.

Participants

Each participant in the structured walkthrough process has a specific role. For a small size project, a person may fulfill multiple roles. The author of the work product is responsible for requesting the walkthrough when a meaningful portion of the product has been developed and is free from casual errors (e.g., spelling errors). The author attends the walkthrough as an observer and answers reviewer's general questions. The author is not a reviewer.

The presenter usually develops the agenda for the walkthrough and presents the work product being reviewed. The presenter should be familiar with the work product and be a member of the project team.

The moderator facilitates the walkthrough session, ensures that the walkthrough agenda is followed, and encourages the participation of all reviewers. The moderator may also be the scribe.

The reviewers evaluate the work product to determine if it is technically accurate. The reviewers also assess whether the project guidelines or standards are being followed, the project requirements are met, and the product is properly prepared.

The scribe takes notes during the walkthrough. The scribe records the errors identified and any other technical comments, suggestions, and unresolved questions. The scribe should not be a reviewer

Tools for Effective Requirements Communication

The following tools can be used

Communicate using Context diagram Communicate using Use-Case diagram Communicate using Business Process diagram Communicate using Scenarios

References

http://www.bpiresearch.com/Resources/Techniques/Requirements_Packages/requirements_packages.htm

http://www.projectmanagementdocs.com/project-planning-templates/communications-management-plan.html

http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/req_gathering_techniques_8CB8E44C.html

http://www.theitba.com

www.blueprintsyscom

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)Version 2.0

http://www.michigan.gov/documents/suite/SEM_Structured_Walkthrough_Process_Guide_275537_7.pdf