Welcome to the Carnival of Business Analysts #3.
The theme of this month’s carnival is requirements planning.
If the concept is new to you have a look at what I wrote before delving into these blog posts.
Firstly a couple of posts on the topic of defining requirements. After all they can be different things to different people and of course in different methodologies.
Jeffery Paul Anderson of Leader4Success writes about the challenge of managing requirements in complex environments, and gives an example of a model used by Digital Equipment Corp in The requirements factory
Roger Cauvin writes on the difference between requirements and design in Wiegers on the Requirements/Design Distinction
Krishna Kumar presents Agile Development and Requirements Management posted at Thought Clusters.
Jonathan Babcock presents an article on keeping the solution out of the requirements in Avoiding the “How” Trap in Requirements Authoring
The beginning of most projects is the planning phase and one of the principle activities is estimating the work activities and the effort and time they will take. Project managers come to you and say how long will it take to define requirements, and how many BAs do we need? Everyone underestimates, even the most experienced people.
I used to recommend analysts break down the tasks, think about how long it all takes, think about the day to day management and activities, the delays in getting into people's schedules and then double your estimate. Then double it again. Other people have other methods;
Scott Sehlhorst presents Scheduling requirements changes - part 1 and Part 2 posted at Tyner Blain, saying, "A two part article on how to manage and plan for changing requirements in an incremental delivery process."
Kupe at B2T Training writes on how each BA’s work plan will be unique and urges BAs to reflect on how they tackle work in Requirements Planning is Personal.
Mike from Leading Answers writes about prioritizing functional and non-functional requirements in an agile context, but of course the principles apply more broadly than just Agile projects in Smart Planning: Balancing Functional and Non-Functional Requirements.
This part touches on some of the activities used to gather and manage requirements. It's not n exhaustive list but it my give you some ideas you can use on your next project.
Rajeev Singh at Portrait of a Business Analyst writes about preparing for interviews and workshops in Process Study and Client Interviews
Andre Oporto presents Getting Started With Use Cases posted at Inside Infogenium.
James Taylor extends a CIO article with 1 MORE thing CIOs should know about requirements posted at Enterprise Decision Management - a Weblog, saying, "A discussion of some of the issues addressed by separating rules and requirements" That’s right; there are requirements and there are other things that you will be collecting or otherwise dealing with along the way, including business rules.
And related to this is the business case, Raj Sheelvant presents Perils of IT Budgeting posted at IT Strategy, saying, "Ways to get project funded"
Writing for your audience
Requirements are a message and they are targeted at a couple of different stakeholders; the sponsor and stakeholders want to know what you plan to build and how it will help them solve their business problems, the developers need to know what they have to design and build, and the testers need to know what they are testing for.
Michael presents Speak their language - Tailor your message! posted at Data Governance Blog, saying, "In any project you do, you must always tailor your message to the audience you are targeting."
Louise Manning presents What drives your stakeholders? posted at The Human Imprint advising a deep understanding of stakeholder motives.
Craig Borysowich writes on 'Managing Buy-in' Keys to Success at Tech Architect, saying, "The keys to successfully making people want to accept change are leadership, vision, and communication."
Brad Kuhn at Carnegie Quality writes about The Role of Testing in the Requirements Process.
Stephan Meyn at Process Mentor writes about some things developers are looking for from requirements in You have requirements
That concludes this edition. A big thank you to all the contributors (and to the authors I added myself.)
Next month's theme is Requirements Elicitation.