Tag Archives: User

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 it 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 you, unfortunately, 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.

After that please read 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.
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 finishing the books please click Topic 10 - Software Construction to continue.

Lessons learned 1:

Problem: Incorrect requirements and constant change of requirements.

Solution: 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.

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:

Problem: Vague requirements.

Solution: Our goal is to clarify our client's problems and needs.

Again analysis is an important tool to clarify our client's problems and needs. It should be done properly using use cases, user interfaces and workflows.

Sometimes we are stuck at analysis, especially when we analyze integration or enhancement needs. In this case a proof of concept or small technical exercises should be done.