How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? Great questions. If you have to write a statement of work, with time/cost estimates, and a list of deliverables – what would you do?
Category Archives: Requirements gathering
Posted in Business Analysis, Product Management, Requirements, Requirements Models, Requirements gathering, Software requirements specification
Tagged actor hierarchy, brd, enterprise requirements, enterprise software requirements, estimation, managing data, scoping, software requirements specification, SRS
5 Comments
Requirements: Knowledge and Understanding
[photo by Henkster]
Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.
You Are Creating Bugs In Your Software
No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.
Avoid the Abilene Paradox
An excellent article by Jonathan Babcock raises a thought provoking idea. When gathering requirements, we can end up with requirements that no one actually wants, because everyone thought someone else wanted it. This is apparently known as the Abilene Paradox, a term coined by Jerry Harvey. We can apply our insights into stakeholders and traceability to prevent it.
Read the rest of the article …
Elicitation Techniques for Processes, Rules, and Requirements
Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?
Posted in Business Analysis, Business Process Modeling, Business Rules, Product Management, Requirements, Requirements gathering
Tagged business rules elicitation, effectiveness of elicitation, elicitation techniques, gathering business rules, gathering requirements, managing data, process definition, process definition techniques, requirements elicitation, requirements gathering techniques, rules elicitation, rules gathering techniques
3 Comments
10th International Business Rules Forum
The 10th International Business Rules Forum is coming up fast in October 2007. Scott Sehlhorst and James Taylor will be presenting Getting it Right. Rules and Requirements in Software on Thursday at the conference. The articles on rules and requirements that he and I have been publishing on our blogs for the last few months are leading to this presentation. The IBRF has graciously offered a 10% registration discount code to readers of Tyner Blain. Read on to get it.
Business Rules Hidden in Use Cases
Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside use cases.
Posted in Business Analysis, Business Rules, Requirements, Requirements Models, Requirements gathering, Use Cases
Tagged alternate flow, business requirements, Business Rules, exception flow, hidden business rules, hidden rules, managing data, normal flow, preconditions, triggers, use cases
12 Comments
Analysis Paralysis and Agile Development
How do you prevent analysis paralysis? That’s the question Barbara opens up for discussion on the Business Analyst Blog. The answer is somewhat simple. You stop as soon as you believe you have something that reasonably covers the goals (or use cases) that you are trying to address. When you have requirement completeness, you move on. This answer is both naive and enlightened- especially when you consider the benefits of an agile development process.
Requirements Details – How Much is Enough?
What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail – for any given product or project, and any given team. The reason we write requirements is so that they can be read. Understanding the readers is the key to determining which details to include in the requirements.
Posted in Agile, Business Analysis, Product Management, Requirements, Requirements Models, Requirements gathering, Software development, Software requirements specification, Use Cases
Tagged business requirements, concise requirements, functional requirements, level of detail for requirements, managing data, non-functional requirements, requirements details, requirements level of detail
1 Comment
Separating Business Rules From Requirements Increases Agility
We’ve written in the past about why it is important to gather and manage requirements. In short, you avoid some costly mistakes, and fix others before they become too expensive. We’ve also started exploring how business requirements and business rules live and play together. But why should we bother to separate business rules from requirements? One reason is to increase your company’s agility.
Read the rest of the article …
Latest Articles
Comments on all Articles
