Tag Archives: Requirements Analysis

Software Requirements Lessons Learned

Lessons learned 1: Emerging requirements.

Problem: Requirements do not exist. They are emerging and often become incorrect and therefore constant change of requirements happens.

Context: Our goal is to ensure project’ success and client’s satisfaction. In order to achieve this goal our delivered solution must solve our client’s problems and satisfy our client’s needs. Unfortunately many clients do not know exactly what they want because they want to try a new business process or would like to enhance their current daily business workflow but the new process or workflow has not been defined yet. They would like us to build something for them to try, then if it does not work in real world then they will switch to something else.

The issue becomes even worse when they do not have time to review our prototype and await a quite complete solution.

Sometimes they consider our prototype a complete solution and want us to revise it around their constant changes for production although the architecture limits of the prototype make it very time consuming for such revision or even prevent us from doing such revision. These limits exist because we only build the prototype for the envisioned requirements, not for the endless changes.

Solution: Analysis and communication are critical to ensure that our deliverables match with client’s needs. It does not matter whether we use RUP or Agile process for development. It does not matter whether we use UML, or boxes and lines, or text, or coded prototypes or paper and pen for describing the problems that need to be solved. Our client and analyst must review, refine and confirm problem specification regularly. Otherwise formal requirements should be modeled, reviewed and approved before design begins to ensure that our project will deliver solution to the right problems.

Lessons learned 2: Vague requirements.

Problem: Requirements are described vaguely and therefore are implemented incorrectly and many detailed elements are missing.

Context: Our clients often just give what they have. It can be a video demo of their existing legacy systems, a list of what they want, some screenshots captured from other similar systems, a long conversation in an email thread, some phone calls. We build a solution based on these artifacts and it turns out that they want something completely different or many detailed requirements are missing.

Solution: Our responsibility is to clarify our client’s problems and needs. Again analysis is an important tool to clarify our client’s problems and needs. Early requirements can be described in any form, including phone calls, emails, screenshots, video demo, feature list. However all of them should then be refined properly using use cases, user interfaces, workflows, story map and prototypes for client to review regularly.

Sometimes we are stuck at analysis, especially when we analyze integration or enhancement needs that have not existed yet and require creativity. In this case a dirty prototype and a proof of concept or small technical exercises should be done so that we can have inputs for inspiring ideas for analysis.