I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.
One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument Continue reading
Requirement statements that begin with the phrase “The system shall” are often referred to as IEEE style statements, because they were recommended for specifying software requirements in IEEE standard 830, and still are in 29148:2011.
The IEEE standard for software requirements specification recommends this method as they have many advantages Continue reading
I find use cases extremely valuable for eliciting requirements. Focusing the discussion on the business process with an informal use case, where each step is simply a bullet point and we don’t worry about using correct use case terminology, makes it much easier to keep conversation on track and productive and helps clarify and avoid misunderstandings that often occur between stakeholders and development staff in requirements discussions. Continue reading
A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.
Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading
Most of you have probably seen this meme on Facebook, Twitter and elsewhere. Generally it is an image, probably taken out of context, of someone demonstrating a lack of understanding, with a comment to the gist of “You’re doing it wrong.” While these images are a little extreme, I’m sometimes reminded of them when consulting on requirements analysis. I’m not saying that organizations are often completely missing the boat, but I’m pretty sure that if they stepped back a bit they’d quickly see their problems for themselves.
Before I start with my first topic in this series, I’d like to quote the IIBA‘s Continue reading
I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.
As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to Continue reading
Test Driven Development (TDD) turns the process of writing code and designing systems around, having developers create an automated test or tests before making any changes to the system at all. If the system then fails the test, the developer makes only the changes necessary for it to pass the test, including possibly refactoring the code or addressing the design if necessary. Then the developer reruns the test.
There are many benefits to this practice. First, Continue reading
Historically the Business Analyst position has been a grab-bag of roles. In some organizations the position is effectively a power user who has expertise in one or two systems and is responsible for analyzing and delivering service requests for those systems. In other organizations the analyst is nothing more than a scribe, responsible for recording meetings and completing documentation. Still more are pure business experts who act as subject matter experts as a proxy for the business.
The founding of the the IIBA 9 years ago started to resolve this problem, just as the creation of the PMI helped define and standardize the project manager position and activities. However, Continue reading
I am often asked this when delivering training on writing requirements. The most obvious difference is semantics. A user story is generally written as a statement of something a user wants to do with a system and for what purpose. For example:
I want to find clothing that is my size.
While a requirement statement is traditionally written in a more formal style, starting with “The system shall” Continue reading
Lack of stakeholder and user involvement is often cited as a primary reason for project failure and the greatest source of project risk. Unfortunately, whether you adhere to an Agile, traditional, hybrid or mixed methology, getting and keeping customers involved in the development process is always a challenge. I explained previously that the most common reasons customers state for not being involved are that they are too busy, they don’t trust the technical team’s ability to deliver, and that they don’t see the meetings as productive.
The first reason is generally beyond a project manager’s control, and the second is a lack of trust between stakeholders and IT that is often Continue reading