Agile OrganizationAgile Software DevelopmentAgile Thinking

You Deal with 3 Project Requirements Per Project

Two types of project requirements are understood, but three types is too much? You usually deal with the checklist that stakeholders provide in the requirements stage. What about the ones that crop up when you start the project? That is the second type. What about the third? In this article at Mountain Goat Software, Mike Cohn explores the three kinds that you invariably work with every project cycle.

Handling Project Requirements

The First Type

The first type of project requirements come from stakeholders and customers. These are the ‘known’ ones that you expect to receive before the project starts. Business analysts usually collect the specifications from stakeholders through interview sessions, workshops, frequent questions, and so on. However, you might not formulate the right questions at the right time. Then comes the next set of project requirements.

The Second Type

Once you start the project, you realize that the clients have not specified some parameters essential to code the feature. These are ‘grocery store’ needs. You had created a grocery list last night and collected it all from the store. Nonetheless, you turn down an aisle and remember you ran out of orange juice this dfmorning. You can even call such project requirements ‘overlooked’ because they develop once you start building the product.

The Third Type

The last kind of project requirements surfaces during the checkout time, i.e., before launching the product in the market or delivering the final product to your clients. You have fulfilled all the known and emergent requirements on the way. The end-users have a look before you deliver, and they realize it would not hurt to add two more features to the prototype. These are nice-to-have or ‘emergent’ items you finally add to the client cart and check out.

Now you have three types of requirements – known, overlooked, and emergent, where the second and third kinds can be categorized under the unknown. Since it is predictable to get the unknown specifications, it is better to be proactive and collect those early in the development cycle.

To view the original article in full, visit the following link:

Related Articles

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.