My Blog

How do we define Implicit Requirements? While attempting to write this blog post I was thinking of defining 'Implicit Requirements' upfront before I proceed elaborating my thought process.Here is the best that I could come up with:

Implicit Requirements are inexplicit requirements that are not directly expressed or captured but are essential to meet System's goal. They are something that are assumed to be "there".

I can sight an example from my current assignment where not capturing implicit requirement had a major impact on our project.

Explicit requirement 1: A Publisher should be able to create an Article, send it for approval and finally publish the Article on the portal.

Explicit Requirement 2 : A Portal user should be able to search Articles published on the Portal.

After the sprint ended we realised that the System was developed to cater to both the requirements, So the publisher could create and publish an Article and the end user could search the Articles using the search functionality. But the search result displayed articles which were published, under approval and in draft state.

Call it a bug or badly defined requirements..whatever... but there was indeed an inexplicit requirement which said: The Articles in draft state and under approval should not be displayed in search result.

This was one example. There can be many more such cases especially related to User Experience (UX) which are mostly implicit. So how do we insure that they are captured at the right time?

1. Using Prototypes/Wireframes: Visual representations always work, while text/documentations can be interpreted in various ways a visual representation of an User Scenario helps you nail many unsaid requirements. Using wireframes for creating screen flows or HTML prototypes is one the best way to capture UX requirement. There is no way that an use case can define how a screen will look or how the screen flow will work and what option should be available to user while creating an Article.

2. Early feedback from the end user: Let the users see, touch, feel and use the system as it is developed. Involve and engage them very early in the development cycle , this will help in getting early feedback from the user and they will be excited about the product. Believe me surprising them with a system at the end is not a good idea.

3. Observing similar product/system available in the market: How is the competition doing? What features do they have in the system? What similar products have to offer? It is always good to know what they have so that you can build better systems.

4. Simply leveraging your experience as Business Analyst: Use your experience, now that i have learned form my present mistake I pretty much sure that in future projects draft Articles would not appear in search results. This is how you become better Business Analyst :)