Effective Communication in Requirements Elicitation: A Comparison
Requirements Communication
-
Upload
santhosh-punniyamurthy -
Category
Documents
-
view
114 -
download
2
Transcript of Requirements Communication
![Page 1: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/1.jpg)
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
![Page 2: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/2.jpg)
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
![Page 3: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/3.jpg)
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
![Page 4: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/4.jpg)
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
![Page 5: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/5.jpg)
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.
![Page 6: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/6.jpg)
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
![Page 7: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/7.jpg)
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.
![Page 8: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/8.jpg)
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
![Page 9: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/9.jpg)
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
![Page 10: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/10.jpg)
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
![Page 11: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/11.jpg)
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.
![Page 12: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/12.jpg)
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
![Page 13: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/13.jpg)
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
![Page 14: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/14.jpg)
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
![Page 15: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/15.jpg)
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
![Page 16: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/16.jpg)
![Page 17: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/17.jpg)
![Page 18: Requirements Communication](https://reader035.fdocuments.in/reader035/viewer/2022081412/544f9a76b1af9fe42f8b474e/html5/thumbnails/18.jpg)
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