Requirement Prioritization

-
Any project will start with a requirement. Requirements are the fundamental building block of a project. Based on the various constraints present we will have to prioritize the requirements in order to build a robust product in successful iterations. In simple terms prioritization means ranking of requirement subject to constraints. General constraints that we face are budgetary, timelines, resources and business impact.It is imperative that the requirements are prioritized and that too early in the project.

The most common method that I use is the MoSCoW technique.This can be broken down as-Must Have, Should Have, Could Have and Won't have.

  • Must Have- These requirements are those which are the most critical pieces of the project without which the project will not be complete. These MUST be taken up. 
  • Should Have-These requirements are important ones but are not as critical as must haves. There could be workarounds available and these SHOULD be taken up based on the constraints. 
  • Could Have- These are nice to have or good to have requirements. Based on the budget, time and resource available these COULD be taken up. 
  • Won't Have- These are the ones with the least priority and can be deferred to a later release based on the constraints. 


There are also other factors that influence prioritization. The ones I use are as below:

  • Cost v/s Benefit- Does the cost justify the benefit for the particular cycle.
  • Regulatory and compliance- Are there any regulatory and compliance requirements because of which we might run into trouble with authorities? Then they have a higher ranking.
  • Dependency with other teams/requirements- If there are pre-requisites, these requirements should have a lower ranking than the pre-requisites. If these requirements are pre-requisites, then these should have a higher ranking.

I use these in conjunction with the MoSCoW technique to prioritize. No technique is complete and we have to keep prioritizing requirements as the project goes.  It is up to the BA to decide the ranking metric (Critical to Low, 1 to 5 etc.). I generally rank my requirements as Critical, High, Medium and Low.

Comments

Post a Comment

Popular posts from this blog

21 tips to understand an AS-IS process

-
Learning the AS-IS process of a system is the first and foremost thing a person has to do while designing a solution to automate it. Here are few pointers on how to go about understanding it. Learn the basic end to end flow Know what are the data entry points Understand what happens to the data that enters a system The places where data are presented to the user The points where communication is send to the customer/user Make a list of systems that interact with the concerned application The different protocols (like SOAP) used to communicate between applications If there is a communication, the acknowledgements being sent/received if any The various validations that happen at various places within and outside the system Check for duplicate validations Make a list of manual interactions that take place in the process Figure out error prone areas- Tip: manual interactions are error prone Thoroughly understand exception handling situations What happens when one of the in...
Read more

Dealing with Integrations of systems

-
Most IT applications will involve some kind of integration with an external system. This external system can be a database or any other application. The communication between systems determines how well the overall system performs. Integrations are crucial links and help us leverage the capabilities of different systems effectively. But, these integration points are vulnerable and information can be lost if all possible scenarios are not addressed. There are basically 2 scenarios that happen when a request is placed to a system- Response (System responds) No response Response can be further broken down to- Positive Acknowledgement with Data Negative Acknowledgement with Data Data- Data can be send with any/both of the responses. Whenever, there is no response from a system, there is loss of data. To retrieve the data we may have to send another request. This is where exception scenarios come and they need to be defined. The following can help us defining the scen...
Read more

Using APIs in integrations

-
What is an API? An application program interface (API) is code that allows two software programs to communicate with each other. APIs expose features and services to developers.  Advantages Re-usability- The same API can be used by multiple applications. The APIs require the input in the right format and they will give the output as per the API contract. Hence, existing functionalities can be shared. Data Abstraction-Only the relevant details are shared (request and response). Data Encapsulation- Collection of features are grouped together to make an API.  Polymorphism- Depending on the request, the response can be varied. Maintenance – APIs are standalone entities and hence instead of enhancing or updating the individual applications that use the services, APIs can be updated and the necessary changes can be communicated to the consuming applications. Challenges APIs may undergo changes and update might be required. This will need ver...
Read more