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 lower cost. In order to achieve this objective, it must fulfill the need of various users. In order to fulfill users’ needs you need to be able to identify their context, problems and needs, then propose software solutions for their issues.

Your software solutions must be built based on its users’ requirements that help them solve their problems. 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 still 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 scenario that may suggest that you should come back to this topic is when you create a software system but unfortunately you find that no one wants to use it.

Alright! What should I do now?

First, please read this book to learn how to develop enterprise software requirements step by step: Suzanne Robertson and James Robertson (2012). Mastering the Requirements Process. Addison Wesley Professional.

After that, please read this book to learn about techniques for engineering software requirements: Karl Wiegers and Joy Beatty (2013). Software Requirements. Microsoft Press.

After that, please read this book to learn how to use models for representing software requirements: Joy Beatty and Anthony Chen (2012). Visual Models for Software Requirements. Microsoft Press.

After that, please read this book to learn how to write use cases effectively: Alistair Cockburn (2001). Writing Effective Use Cases. Addison-Wesley.

After that, please review this standard so that you could create a quality software requirements specification for projects require high formal specification: ISO/IEC/IEEE 29148:2011(E).

After that, please read this book to learn how to use user stories for documenting and communicating requirements: Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional.

After that, please read this book to learn how to discover the real problems that need to be solved: Jeff Patton and Peter Economy (2014). User Story Mapping. O’Reilly Media.

After that, please read this book to learn how to manage and communicate requirements across large teams: Dean Leffingwell (2011). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.

After that, please read this book to review the core concepts and gain insightful advice when facing challenges in discovering requirements: Karl Wiegers and Candase Hokanson (2023). Software Requirements Essentials. Addison-Wesley Professional.

After that, please read this book to learn how to manage requirements for large government projects: George Koelsch (2023). Hardware and Software Projects Troubleshooting – How Effective Requirements Writing Can Save the Day. Apress.

After that, please read this book if you want to obtain a PMI-PBA certificate: Project Management Institute (2015). Business Analysis for Practitioners – A Practice Guide. Project Management Institute.

Terminology Review:

• Elicitation Techniques: Interviews, Questionnaires, Group Meetings, Personas, Brainstorming, Document Analysis, Apprenticing, Observations, User Interface Analysis, System Interface Analysis, Reverse Engineering.
• Business Requirements.
• Stakeholders.
• Sponsors.
• Customers.
• Users.
• Business Analysts.
• Terminologies, Terms.
• Problems.
• Business Goals.
• Evaluator Pitch.
• Work Context Diagrams.
• Executive Summary.
• User Requirements.
• Glossary.
• Business Rules.
• Business Use Cases.
• Scenarios, Business Workflows, Business Processes.
• Storyboards.
• Process Flows.
• Activity Diagrams.
• Swimlane Diagrams.
• The Brown Cow Model.
• Business Rules.
• Domain Models.
• Business Data.
• Entity Relationship Diagrams.
• Data Flow Diagrams.
• State Models.
• Features.
• Feature Model.
• Feature Tree.
• Project Vision.
• Software Requirements.
• Functional Requirements.
• Use Cases.
• Non-Functional Requirements.
• Software Requirements Specification.
• User Stories.
• Business Values.
• Story Map.
• Product Backlog.
• User-Interface Prototypes.
• User Interface Flow Diagrams.
• ISO/IEC/IEEE 29148:2011(E).

After finishing software requirements, please click on Topic 11 – Software Construction to continue.