Michael has posted five (plus five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We have re-organized these tips into three general areas of guidance and provide our thoughts.
Agile / Process Improvement / ROI / Software development
Posted on:
Two big benefits of incremental delivery
Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes some valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.
Design / Interaction design / Requirements / Requirements gathering / Software development / Software requirements specification / UX
Posted on:
Interaction Design Process Overview
Interaction design, as described by Alan Cooper in The Inmates are Running the Asylum, is a process for designing software by focusing on the most important users. Unlike traditional requirements gathering and solution design processes, interaction design focuses on the goals of a specific class of users, represented as a persona. Those goals are considered when defining scenarios that represent how the primary persona will use the software. The combination of goals and scenarios leads to design artifacts and a functional specification. We will explore these steps in more detail in this post.
Requirements
Posted on:
Software requirements for migration projects
A very common enterprise software project is the replacement of a legacy system – migrating functionality to a new system. This type of project usually has very different constraints than a “new application” project. We will look at the characteristics of migration projects to understand how we should approach them to assure success.
Communication / Requirements / Software development / Software requirements specification
Posted on:
Software Requirements – Process and Roles
Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.
In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.
Communication / Consulting
Posted on:
Top Five Ways To Be A Better Listener
Effective listening skills yield great requirements The better you are at listening, the more people will want to tell you. If you’ve ever watched The Actor’s Studio, you’ve heard over and over that the most important skill in acting is reflective listening. A marriage counselor will tell you that step […]
Process Improvement / Requirements / ROI / Software development
Posted on:
The Best Way to Improve ROI is With Good Requirements
Statistics that support the critical need for requirements management improvements…
Foundation series / Process Improvement / Requirements / Software development
Posted on:
Foundation Series: Structured Requirements
Karl Wiegers wrote the book on structured requirements – Software Requirements, 2nd Edition, Karl E. Wiegers. If you are involved in managing requirements, you should own this book. Even if you don’t follow his approach to managing requirements, or don’t like how he deals with use cases, you should still […]
Consulting / Process Improvement / Requirements
Posted on:
Why We Should Invest in Requirements Management
Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments…