All Entries Tagged With: "Specification"
Quoteworthy: George Orwell on “Scrupulous Writing”
“A scrupulous writer, in every sentence that he writes, will ask himself at least four questions, thus: 1. What am I trying to say? 2. What words will express it? 3. What image or idiom will make it clearer? 4. Is this image fresh enough to have an effect?”
Politics and the English Language, 1946
— George Orwell
Give ‘em Pictures!
One of the surest ways to ensure project success is to get “pictures” in front of the users/stakeholders as early in the process as possible.
Quoteworthy: Kulak & Guinney
An appropriate and complete requirements specification does nothing to ensure a successful implementation; however, it makes it possible.
- Kulak & Guinney
Time Travel for Context-free Use Cases
Yes, sometimes we BA’s need to think of creative ways to help us withhold the technology and implementation detail from our requirements.
Bookmarks & New Favorites (09-38)
a few of the articles I found “bookmark-worthy” over the past week.
More on Separating Rules from Use Cases
Keeping business rules out of the flow of events makes a use case easier to maintain and reuse.
Use Case Basics: Keeping it Simple
A few simple tips for identifying and documenting use cases.
Could requirements analysis be automated?
Could systems and software be used to take the place of the requirements analyst?
Structured Analysis & Big, Thick Documents
Great book on modeling & systems analysis and yet another critique of “big, thick documents.”
Patterns and the Evolving Business Analyst
Let’s focus on what I consider the capstone to development and “evolution” as an analyst; the ability to learn, recognize and apply patterns.
Bright Idea on Requirement Character Limits?
Adam Feldman, blogging from Bright Green Projects’ “Bright Ideas” blog poses a fun and interesting question. Twitter limits entries to 140 characters. Should we do the same for requirements?
Google Wave for Business Analysis
The social web is abuzz with news on the upcoming Google offering, Google Wave.
Did I Really Write That?
As I was scanning through some of my old documents, I found that I wasn’t that thrilled with a lot of my older work. Ever had that happen to you?
Recommended Reading (09-11)
Here are some of my recently bookmarked items on business analysis and related topics that I thought I’d share.
Analysis Model Meme
Craig Brown, who runs the fabulous project management/business analysis blog Better Projects made a call for participation to various bloggers in that niche to list the first and last analysis models we’ve used at work. Being the good sport that I am, here’s my reply.
Use Cases or User Stories? Read Up!
There have been some really interesting articles in recent days and weeks that have been comparing use cases and user stories, and highlighting the advantages of each. I’ve cherry-picked some of the best from my collection of bookmarks to share with you here.
Regardless of what method you use, it is good to be familiar with the available options and their relative strengths and weaknesses.
Use Case Basics: Distinguishing Between Exception and Alternative Paths
A while back I was involved in a discussion during which someone commented that because exceptions are really just alternatives to the main success path, then there’s really no need to bother distinguishing them from other alternatives to the main success path.
While I knew that idea didn’t feel quite right, and there must be a good (and probably simple) response, I didn’t have one at the tip of my tongue at the time. And I admit, it wasn’t a burning issue that kept me awake at night, so I never thought much about it afterward until I came across this description of why we differentiate between the two.
Weekly Digest 08-43
Cockburn on methodology, free software, funny about IT & the business, great new business analyst blog, etc.
Vision Statement Form and Function
Form and function of the product vision statement.
How hard could it be to design the stop sign?
I recently stumbled upon this video, got a kick out of it and thoughts I’d share. It is basically a video parody for the process of designing the stop sign if the project were kicked off in 2008. There have definitely been times in my career as a BA where I’ve felt like the poor chap trying to design to the customers’ specs.
Oh.. and for geeks like me who saw this and then wondered when we really did get the stop sign, here’s an interesting link.
Looking for Sample Requirement Specifications and Templates?
Quick, simple tips to find sample requirement specs, templates and other sample documents.
Quick Tip to Help Identify Use Case Actors
A few thoughts on identifying use case actors and a job-aid that may help simplify the effort.
More on User Stories
How are user stories different from use cases and from traditional requirements?
A Couple Tips on Keeping Use Cases Simple
Use cases are atomic functions that are portable and not dependent upon a certain situation. They are requirement “objects” in the “object oriented” sense. I think that modularity and “reusability” are among the most valuable aspects of using use cases to express requirements.
This modularity can be undermined, though, if we allow our use cases to get too far into specifics and implementation detail.
The book “Use Cases: Requirements in Context”, by Kulak and Guiney, provides us with a couple simple ways to self-check our use cases to ensure that they include the appropriate level of detail, but aren’t reaching too far into design.
Precision Tools: Requirement Structure
I recently posted about the need for accuracy and precision in requirements. In that post, I mentioned that natural language requirements are probably the least precise format for expressing requirements. Many BA’s, myself included, write specs composed of natural language requirements and a few flow diagrams for clarification and context. So, given that natural language is not inherently precise, how do we at least make them as precise as possible?
Good Requirements Are More Than Just Accurate
The business analyst’s job is not complete if the requirements are documented and accurate but lack precision.