Wolfram Alpha is a great way to find a fact and do some analysis about it. You might think that after 19 days of being available to the public that I would understand what it’s all about as a user. Just like Mathematica, I think this product is a tad ahead of its time. This quote from their site: “Wolfram|Alpha’s long-term goal is to make all systematic knowledge immediately computable and accessible to everyone” is now much more meaningful after having used the service: “immediately computable” means a whole world of analysis can be at your fingertips, and “systematic knowledge” is another phrase for data and facts.

Now, there are some recognized shortcomings but by-and-large, as a proof-of-concept, it’s fantastic! The above link should bring you to a query state that lists the following major US specialty retailers: Staples, Office Depot, and OfficeMax. Now what I was trying to do was to find information quickly about this particular sector of retailers, provide a basis to generate an estimate on the size of the market for office supplies, and see data points relative to each other. And of course, it did so beautifully.

There’s plenty more work to follow, however. I think there are two key high-priority enhancement projects Wolfram Alpha should consider for their next release cycle:

1. a simplified and standardized (mathematical?) grammar structure, and
2. a fact-drilling capability.

The first suggestion would greatly help users understand how to structure their input and reduce the incidence of the “don’t know how to handle the input” page appearing to users. After all, I can’t think of a single language that doesn’t have syntax with which to standardize expressions and context. And at the same time, I don’t think one system can understand every single kind of expression and context from a myraid of users without extensive effort into a (in my opinion) futile effort.

The second suggestion would be a means to offer transparency to the facts presented by the engine. Similar to Wikipedia and to the tradition of citations in written works, Wolfram Alpha should consider a way to cite every single fact in its database. After all, each one should be verifiable in its own way, and the source content would go a long ways to confirming that work. Good luck to the Wolfram Alpha team, I wish you the best of success!

Recommendations: Put in a grammar/syntax structure to help users understand how to input their queries, while keeping it at a minimum. And don’t forget the beauty of the Web being built on hyperlinks, so link to your facts where possible!

My perspective comes from lots of hands-on experience with each of the three groups. Creative folks need time to let ideas marinate and mature into thoughtful assets. Technical folks (good ones, anyway) need scope to build the best possible product (if only I had a dime for every time a developer’s asked me “Well, if I do it this way it can work okay, but I think it’s better to do it this way because [insert comment about future capabilities or cool functionality]“, I’d be rich!). And of course, we can’t forget business folks, whose tolerance for time seem to fall lower every day. How can you get the three groups working together?

Recommendation: Building mutual respect and condensing each group’s issues into soundbites for the other groups is my approach to handling any initial situation. Project managers must have a strong curiosity for new domains and the nuances of each group’s work and background, which will help them argue for each side. This kind of position will guide a project to success for all stakeholders since it strikes a good balance and effectively negotiates a lot of tension out of the situation. However, when I’m in between a rock and a hard place, I have to side with the money but not without a fight for quality and extensibility. Doing right by the client is my mantra and I would never sacrifice that until I’m kicked out of the building.

What do you think?

The trick is how to write a good requirement, for any number of situations. Part of the answer is to follow this convention:

The [your words here: system, actor, function, dependency, etc.]
must [your words here: do, process, store, etc.]
to [your words here: accomplish a goal, serve a purpose, etc.].

and to focus on the “what” (substance) of the need as opposed to the “how” (design) of the need. In addition, there are 8 key criteria that each requirement should satisfy to be considered well written.

As a business analyst, you should think about addressing the following points to evaluate how well written the requirement is:

• Necessity €“ A “must have”. Conversely, it helps to avoid gold-plating and gives you a prioritization tool during the build phase of work.
• Unambiguous-ness €“ Use assertive words without vague terms. This also helps the writer/stakeholder focus on the “what” of the product/service/result as opposed to the “how” and proactively reducing interpretation issues.
• Testability €“ Can be verified by inspection, analysis, or demonstration, which means that there’s a qualifying attribute to almost everything based on the idea that you know it when you see it.
• Conciseness €“ Conveys what is required and is easy to read yet. If you end up writing a page-long requirement, it’s time to make it more atomic.
• Consistency €“ Does not contradict other requirements and uses a known vocabulary that should be defined for the layman (or at least the wider group).
• Completeness €“ Does not require you to look at additional text to know what the requirement means. At the same time, requirements may be related to each other, which then requires the writer to add a separate requirement that talks about interaction between multiple requirements.
• Feasibility €“ A requirement that can be implemented. Typically, time is a factor, but cost and available resources will all ultimately play a role in what you deem feasible or realistic.
• Traceability €“ Has a unique identifier and is tracked through the development of the product/service/result. Along with testability, this attribute plays a role in ensuring that things do not get lost in the cracks.

The above list was adapted from here based on my own experience, and there is a wealth of material on the Web and in print that follows these conventions (or their spirit). Unfortunately, despite the volumes dedicated to this topic, it still frustrates users and is a task that is taken lightly because it is time spent with seemingly less tangible benefit up front. I have had many experiences where the team will ask “What did (insert name) mean when he/she wrote this,” which resulted in time wasted, potentially incorrect coding to occur, and costly testing time and effort down the line that reveals something “wrong” with the system but is hard to define or pin down.

Recommendation: Do the work upfront, and you’ll save time and headache later. As a business stakeholder, focus on the “what”, and allow technical subject matter experts worry about the “how” (which they are supposed to do anyway). Well-written requirements based on necessity, unambiguousness, testability, conciseness, consistency, completeness, feasibility, and traceability will save the day.