Requirements Prioritization Techniques You Should Know About

Software development or any other project concerning numerous requirements, monetary limitations, and constricted targets often dictate the need to prioritize requirements. The necessity to prioritize originates from a very simple fact - that we don’t have sufficient resources to work on everything we come up with. Hence, it is essential to make assessments on which set of requirements are required to be executed in the beginning and which ones can be pushed for a future release.

When prioritizing requirements it is particularly vital to ensure stakeholder’s participation in the entire process. Stereotypically, requirements are elicited through workshops, documented sources, and prevailing systems and processes. These facts are then documented and proposed to the stakeholders for prioritization and/or exclusion from scope. 

Several techniques on how to prioritize requirements have been developed, however some work well on small number of requirements, while others are appropriate for complex projects with many decision-makers and variables. This list of requirements prioritization techniques offers an overview of common practices that can be used in prioritizing requirements.

 

1. Ranking

Rank requirements on an ordinal scale, and give each requirement a different statistical value based on its significance.

For example, the number 1 can signify that the requirement is the most important and the number n can be allocated to the least important requirement, n being the total number of requirements. This technique works best when dealing with a single stakeholder.

 

2. MoScoW Technique

As an alternative to numbers, this technique uses four priority groups: MUST have, SHOULD have, COULD have, and WON'T have. With this technique, stakeholders can prioritize requirements in a collective fashion. The acronym represents the following:

• MUST (it is Mandatory)
• SHOULD (it is Of high priority)
• COULD (it is Preferred but not necessary)
• WOULD (it can be postponed and suggested for future execution)

3. Bubble Sort Technique

In this technique, one needs to basically compare two requirements with each other. If one finds out that one requirement should have superior priority over the other, they are swapped across accordingly. Continue this approach till the final requirement is appropriately sorted. The result is a list of requirements that are ranked.

 

4. Hundred Dollar Method

In this technique all stakeholders get abstract 100 dollars, which they can then allocate to the requirements. As such, the stakeholder may give all 100 dollars to a single requirement, or the person may distribute the points more evenly. The higher the value assigned to each requirement, the higher the priority of the requirement. At the end, the total is calculated and the requirements are arranged based on the number of points they acquire.

 

5. Five Whys

With five whys, the analyst asks the stakeholder repetitively why the requirement is essential until the prominence of the requirements is recognized. The answers disclose whether the requirement is crucial or can be postponed once the priority is determined.

 

Conclusion:

So, you need to choose the prioritization technique which satisfies your needs and accomplishes your objectives in the least amount of time and with nominal resources.

About Author:
Gurpreet Kaur Gaga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: gurpreetkaur.gaga@spluspl.com

 

Importance of ‘Minute of Meeting’

Analysts predict that the latest inventions in product management will significantly influence how we use our new technology and different ways to do things. For example, there is a major change in software project management these days. New methodologies emerge in the market for which it allows us to handle the complex issues and modifications so easily as compared to traditional methodologies.

So if we talk about new software development methodologies like Agile, lots of new technique comes into the picture. One of them is client interaction / communication on the daily basis. Scrum call is one of the most important steps in agile, where we have to interact with the whole team and client on daily basis for updates. So if you interact with the client over the phone call on a daily basis then most of the important discussion and key action items happen on call only instead of email. For tracking or monitoring such discussion there is a document which is called ‘Minute of Meeting’.

There is a number of format for Minute of a meeting, its depend on the origination which one they would prefer but the purpose will remain the same to track an important discussion, key action item with who's accountable for what and who was present at a meeting.

Preferably any minutes should reach the group within 24hrs hours of the end of the meeting. And it is necessary to have a place where each version of MOM is saved for future reference.

Why is it important to have Minutes?

Minutes are important for both who was at the meeting and who miss the meeting. Memories are unreliable so it is very useful to have a written record of the meeting, including actions and decisions. The minutes are a good reference for attendees refresh memories.

What tasks are involved in taking minutes?

Normally before of the meeting, one of the attendees is designated as the minute taker. The minute taker generally completes the following tasks:

• Note down the name of attendees
• Taking notes for discussion and action items
• Prepare minute as per company format
• Distributing the minutes to all relevant people

What should write down in minutes?

While taking minute we should note the following:

• Name of attendees
• Agenda
• Who discussed what?
• Key points in every discussed topics 
• What are the key action items from whom

It is not possible to write everything down, so don’t try just note all the key points with respective names.

Tips for Taking Minutes

Taking minutes is easier in well-managed meetings than in unstructured meetings,

Here are few tips for good minutes

• Ask for clarification after meeting to respective person if you miss something
• Ask for help from other attendees if you are also participating in the meeting and have forgotten to take notes
• Prepare a draft version before a meeting which will help to take notes easily
• Use the past tense, the minutes are distributed after the meeting
• Before sending minutes cross check name of attendees, target dates if any and accountable person name for the respective task.

Conclusion

Keeping good records is a good way to lead any project as the minutes are an important tool for fulfilling this duty. Minutes primarily serve as a tool for helping manager remember what the team decided at previous meetings, and secondarily as a way to keep our co-op’s members informed about the actions of their management.

About Author:
Niraj Patil is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: niraj.patil@spluspl.com

SRS IN A PINCH

A SRS document (Software Requirement Specification) is a document where a company’s understanding of their respective client’s system requirements are documented. This usually happens prior to any design or development work has actually started. This marks as an assurance that both the parties have understood each other’s needs at that point of time. The SRS document will depict only those requirements which are necessary from the project development’s point of view.To derive the requirements we need to have a clear and thorough perspective of the products to be developed or which are being developed.

The functionalities and capabilities of a software system are documented in explicit and precise language. The SRS also acts as a blueprint for completing a project with as minimum cost growth as possible. 

CHARACTERISTICS OF SRS:

In order to avoid the above scenario, following characteristics should be kept in mind while writing a SRS document:

• Accurate

This is the first and foremost requirement. The development team will not reach anywhere if the SRS, which is the basis of the process of software development is inaccurate.

• Complete

A complete requirements specification must precisely define all the situations that will be encountered and the system's responses to them. It should not include any unnecessary features which might not be required by the system.

• Consistent

The document should be consistent throughout. It should be understandable by a user who not involved in the project too.

• Prioritization Of Requirements

The requirements should have a specific order of priority and preference. It should not simply be a wish list.

• Verifiable

A SRS is verifiable if and only if, every requirement stated in the document is verified as per the needs. A requirement is verifiable if, and only if, there exists some finite cost-effective process with which user can check that the software product meets the requirement.

• Modifiable

A SRS document should be written in such a manner that it can adapt the changes given by the development team or the client at any given point of time.

• Unambiguous

A SRS is unambiguous if, and only if, every requirement stated therein has not more than one interpretation.The use of weak phrases or poor sentence structure will lead to misunderstandings.

Conclusion: 

When the client’s requirements are defined completely, only then can one write a SRS document of top notch quality. That coupled with a natural language that incorporates strength and weakness, quality indicators, technical communications, professionals well-trained in requirements gathering, template designs etc are in the best position to create and add value to such critical project documentation.

About Author:
Disha Udani is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: disha.udani@spluspl.com

Smart Requirement Gathering for Efficient Development

With IT Projects becoming bigger and the need to execute them faster becoming more and more crucial every day, the initial task of Requirement Gathering needs to be optimized to fit this need. The Requirement gathering process is the nucleus of the development activity and thus the results of the requirement gathering process reflects on the all the tasks of the project throughout the course of the project. 

Requirement Gathering based on Project styles?

The ways to approach a requirement gathering process for a Business Analyst differs from Project to Project, for instance in a Waterfall style project the requirement specification document will need to have a consolidated content to enable efficient development throughout the lifecycle of the project, whereas an incremental or an Agile style of project needs the requirements to act as a trigger for Development and further improvisations. So clearly there is no well-defined success formula to collect requirements efficiently, however by identifying the high level need of the project, the development process to be followed these requirement gathering techniques should be defined accordingly.

A few essentials to be followed:

• Ask the right and wrong questions
• Team contribution while creating a Requirement Specification
• Create a supporting cast for the requirements
• Revisit and update Requirements on a timely basis

Ask the right and wrong questions:

A requirement gathering is not just about gathering a passive set of requirements, it about understanding all the aspects including the need for the improvisations. The brainstorming session with the stakeholders needs to be a session where questions are asked regardless of the complexity of the system. It’s important to have a smooth flowing understanding with the stakeholders and it is important that even if there are questions which come up after a meeting, a requirement gathering should have majority of the questions answered. For questions which are not answered, a possible solution and understanding should be provided by the Business Analyst to clarify the requirements.

Team contribution while creating a Requirement Specification:

It is important to discuss the requirements/questions as a team. It’s a misconception that the Business analyst is the owner of the entire process however it is vital to have a development perspective through discussions/brainstorming sessions with the different members of the project. Right from the testing team to the development team, their concerns/questions on understanding a system can be vital in the questions set asked to the business owners/stakeholders.

Create a supporting cast for the requirements:

The Requirement specification document is the representation of the Requirement gathering process, but it’s a great utility to support the document with some additional tools. Sharing the understanding of the requirements with the business owners using tools like dynamic or static wireframes, dynamic mockups of the system (to allow users to navigate) can be vital in making the requirements concrete. These tools can also be used as a playback before sending out a finalized document for approval of the gathered requirements. It is also vital to keep these primary and secondary set of documents updated throughout the course of the development activity.

Conclusion: 

The Requirement gathering is a crucial initiation phase that sets the tone for the development activity to be followed. Hence understating the implications of the conclusions drawn at the end of this phase is vital. As specified earlier, there is not a defined set of questions or a defined process to carry this process out, but understanding the complexity and then adapting the requirement gathering process accordingly helps to make the process smoother. The success of a requirement gathering can be properly quantified during the development phase when the Requirement Specification document which is the result of the Requirement Gathering process acts as the primary reference for the development as well as testing teams.

About Author:
Chandan Amonkar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: chandan.amonkar@spluspl.com