Tag Archives: Story Map

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.


  • 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.


  • 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, domain models, 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.
Lessons learned 3: Requirements dispute.

Problem: Requirements are described only at business level, and therefore many detailed elements are not implemented. However customer does not have time to review the implemented system. When the project is in transition phase it turns out that most of the implemented requirements are non-compliant.

Context: In order to reduce development time and cost many teams just take business requirements and implement them. They may create a work break down structure or a detailed task list for completing these business requirements. However these tasks just describe HOW a business requirement is implemented, NOT WHAT it should be. It means that both USER functional and non-function requirements of a BUSINESS requirement are not analyzed. The situation become bad when it costs too much for a customer to review an implemented business requirement regularly, so the customer just let the teams finish their work. When the project is in the transition phase it turns out that many details of user requirements are not implemented.


  • Critical business requirements must be refined into appropriate user stories or use cases.
  • Non-function requirements must be incorporated as notes into each story or use case.
  • Adequate UI sketches (mock-ups) or prototypes or captured screens should be created.
  • Test cases should be created and agreed to validate requirements.
  • A single repository for all requirements should be used for change management and traceability.
  • Architecture and/or proof of concept should be created to discover integration limits of specific requirements.
  • User manual should be created for each business requirement.
  • More importantly, frequent requirements and system validation should be done by a customer if possible to improve the understanding about requirements and prevent communication gaps, especially when an Agile development method is selected to reduce the time and cost. Customer’s assessment must be done regularly (at least weekly, preferred daily if an Agile method is selected), not just once when the project is about to be closed.


Topic 9 – Software Requirements

Why do I need to learn about software requirements?

Your software can only be successful if it helps people do their work better, faster, with a lower cost. In order to achieve this objective, it must fulfill the need of various users.

To fulfill users' needs you need to be able to identify their context, problems and desires, then propose software solutions for their issues.
Your software solutions must be built based on its users' requirements. So you need to be able to collect, document, manage and validate their requirements. Software requirements engineering will provide you knowledge for completing these tasks.

Do not waste your time to create software that NO ONE will use. Your software will only become useful if its requirements are correctly engineered.

What can I do after finishing learning software requirements engineering?

You will know how to elicit, document, manage and validate software requirements so that they can be used for creating your software.

Hmm! Is it really useful?

If you have a doubt about its usefulness then you can delay learning about software requirements until you are tasked to create a software system but you do not know where to begin or what are the inputs for your coding.
Another scenarios that may suggest that you should come back to this topic is when you will have created an application but then unfortunately you find that no one wants to use it.

Alright! What should I do now?

Please read 
- this Suzanne Robertson and James Robertson (2012). Mastering the Requirements Process. Addison Wesley Professional book, and
- this Karl Wiegers and Joy Beatty (2013). Software Requirements. Microsoft Press book.

After that please read this Joy Beatty and Anthony Chen (2012). Visual Models for Software Requirements. Microsoft Press book.

After that, please read this Alistair Cockburn (2001). Writing Effective Use Cases. Addison-Wesley book.

Then please review this ISO/IEC/IEEE 29148:2011(E) standard so that you could create a quality software requirements specification for projects require high formal specification.
After that please read this Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional book.

After that please read this Jeff Patton and Peter Economy (2014). User Story Mapping. O'Reilly Media book.

After that please read this Dean Leffingwell (2011). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional book
After that please read this Project Management Institute (2015). Business Analysis for Practitioners - A Practice Guide. Project Management Institute book.
After finishing the books please click Topic 10 - Software Construction to continue.