Certain methodologies suggest that you identify system Actors early on in the process of defining your problem and solution. I think this is a great idea, and this is why.
1. Identify the Problem(Common techniques used to find the problems behind the problem are brainstorming, fishbone diagrams and Pareto diagrams.) 1. Ask the group: What are the problems (aka business
Found this oldie but goodie in a file named – Requirements Management Task List. While not exactly what I would put together today, it still holds a lot of value
The Project Glossary defines terms/acronyms relevant to the project. You all probably know that. What may be news to some of you is that it singlehandedly provides a valuable and
The other day I overheard someone say that all they needed to write code was the list of functional requirements–that they didn’t need the accompanying use case (that we were
A Strawman Workflow for Requirements Change Management One of things we are asked to do on almost every project is provide guidance on defining the workflow for managing the changes
The title of this post isn’t what it appears. This isn’t going to be a post about how managing requirements is a non-negotiable element of successful software development projects. Although,
How often should I be reviewing my requirements with members of my project team? By requirements I mean everything from high-level business needs (e.g. stakeholder requests, business requirements, vision and
Don’t miss out on this opportunity
and request a conversation today!
