The Requirements Engineering Conference is just around the corner.

Its being held in Sydney Australia September 27th- October 1st 2010.

If you are attending this conference don’t miss out on the  Requirements Engineering Education and Training Workshop that is taking place September 28th.

Do you want to broaden your skills? Learn new techniques?  This is the workshop for you.

This workshop will address issues related to Requirements Engineering education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching and assessing skills needed by an effective requirements engineer.

Curriculum design

• Curriculum for undergraduate and graduate level RE studies
• Mapping RE elements from the SWEBOK (Software Engineering Body Of Knowledge) to RE curricula
• Identifying and incorporating specific RE related topics into the general curriculum and/or software engineering courses
• Curriculum for industrial training programs

Techniques for teaching specific RE related skills

• Creative methods for teaching stakeholder identification, requirements elicitation, negotiation and consensus building, requirements writing, and other critical RE skills
• Specific tools, exercises, and assignments developed to support RE skills training

Assessment methods and practices of RE knowledge and skills

• Which assessment method to use: exam, test, case study, essay, report, presentation, or something else?
• Strategies for assessment of learning soft skills
• What should students be able to do as a result of learning RE?
• Methods of objectively measuring assessments

Effective pedagogical methods for teaching RE skills

• Survey results related to topics such as the effectiveness of teaching methods, RE skills needed to be effective in industry, skill mismatches between graduating students and industry needs etc.
• Studies into the effectiveness of requirements engineering educational practices
• Experience reports including industrial training and university level curriculum

Do you want more information?

http://www.re10.org/

http://users.cscs.wmin.ac.uk/REET10/Overview.html

The Seilevel message board is back up! The message board was on a hiatus for awhile but we’ve cleaned it up and revamped it. We are happy to say its back up and better than ever.

Do you have questions or comments on software requirements, requirements gathering, elicitation, conflicting requirements?

Do you have questions about business objectives?

Want to discuss a tool?

Are you looking for requirements resources? Use case questions?

Questions around getting your business analyst certificate?

General questions as a BA?

Want to discuss Agile or BABOK?

It’s all there plus much more. If you are not a member sign up today.

Check out our new and improved message board  today.

Seilevel will be at the University of Texas Career Expo on September 8th.  The expo is being held at the McCombs School of Business.

We will be there talking to current business students about a career path as a Requirements Analyst/ Business Analyst.

We are looking for people who:

• are excited to learn completely new subject matter
• have a history of success in everything they do
• are willing to admit and learn from their mistakes
• consistently perform in the top 5% of the population
• love interacting with people
• have a history of great team leadership
• are crazy about work and play

Do you want more info? Interested in our Requirements Analysts/ Business Analyst position once you graduate? You can check out more info on the Career Expo here and our full job descriptions here.

Over my professional years, I have learned one really important life lesson: Every time I make a mistake, I learn a lot. So I was thinking about that in the context of being a BA. I believe that making mistakes is not such a bad thing and instead should be seen as a wonderful opportunity to learn more about how to be a better BA. These are some of the mistakes I encourage you make….or if not to outright make, at least be ok when they happen and recognize the lessons learned.

1. Miss a requirement: As BAs, we know we must do everything we can to not miss requirements. But here’s the deal, we are going to miss requirements, I guarantee it. There is no such thing as a perfect requirements document. So the sooner you can miss one, have it later be realized, and see that you can survive it, the sooner you realize that it’s ok to not be perfect and there are processes to recover.
2. Hire someone who actually doesn’t want to be a BA: Working with a BA who doesn’t love the job as much as you will help you recognize even more so why you do love it. These people will likely not work as hard as you at the job, so you will be frustrated. And with this you will learn how absolutely important it is to hire the right people. I do believe hiring the wrong folks will ultimately help you hire more of the right ones over time by helping you hone the set of skills and personality traits you need.
3. Ignore the details: Go on, get lazy about the details and see what happens! As an example, you really have to follow the template formatting exactly and worry about your style headings? Well, I’m super detail-oriented, but sometimes I wonder rather I really have to be as careful as I am about those pesky details because they can be so time consuming, especially if we are working long hours. Well, once you make the mistake of not being detail oriented, and someone complains or you figure out you really needed to be more detailed and have a harder job to recover after the fact – then you will gain the appropriate level of respect for the details that do matter.
4. Manage your requirements in Word: I’m willing to bet, you’ve already done this one! Haven’t we all? But having a project right now where they refuse to use a tool and we have instead got 100 different documents of information to manage and not trip over each other with is reminding me once again that you must use one at all costs! With brand new BAs who don’t really know the value of using a tool over something like Word, I actually like to let them feel the pain of this fully before I force them into using a requirements tool – otherwise they won’t really adopt the tool and will be frustrated by it being forced on them.
5. Write 1000 shall statements, call it done, dump the 500 page doc on your developer’s desk and walk away: Check back in a few weeks later and see if the developer has used it. Or don’t, because we know they haven’t. One of the most important lessons I learned was from someone else’s mistake, though I had also been guilty. I had to come into a project and read 2000 shall statements to get up to speed on it. Needless to say, there was no way I had a clue about what the system really needed to from that document, and neither would a developer. If anything I just had  great reading material to put me to sleep at night! Anyway, in going through this, I realized I had done this very thing myself. I had written the long documents of requirements and was so proud because I was sure it was all there, written down in plain English. But up until that point, I hadn’t considered whether the stuff I’d written down was actually consumable. And with that, I learned the awesome lesson that you really do need models (like RML®!) – to add visual context and better explain the requirements.
6. Have a full on failure project: I really don’t want to promote purposefully failing your projects, but if you are in one that is failing, take it as a valuable opportunity to learn that you alone cannot save the world. Here’s the deal, most of us aren’t performing brain surgery (though if your project IS related to brain surgery, that’s a great example of a project NOT to make this mistake on!!). But rather, most of us are working on corporate IT software, so if you screw up, no one is going to die. Also, many of us have the type of personality that really does want to please our end users and help build the right software. So when things aren’t going well, it’s extremely frustrating for us – making this lesson so hard to learn. Once in a failing project, I found myself pouring more and more of myself into it, only to continuously be disappointed…and  tired. But I learned so much by stepping back and looking at why the project was failing – recognizing all the things I did right and learning from all the mistakes that myself or others made. But the big takeaway on this one for me was that you don’t have to save the world on every project. And if a project fails, it’s likely not your fault and not your responsibility to fix it. Just show up and do your best BA work and learn what you can do better next time!

On our projects we are often asked to provide our requirements to the development teams with business prioritization.  I’ve been in meetings with my business stakeholders where we  have sat in front of a list of requirements and attempted to prioritize them one by one.  In my experience, this effort ended up prioritizing the list based on the stakeholders “gut feel” of the requirements, due to political clout, or just people being more demanding than others.  Using this gut feel method does not ensure that the critical requirements actually make it “above the line” for project development. 

After a period of time I realized that these prioritization discussions were repeatedly following the same path.  I wanted to be able to break some of the stalemates, and by providing some additional criteria to be used in these prioritization reviews. 

I came across an article called “Requirements Prioritization” on the www.requirements.com website.  To summarize, the article lists out several options for requirement prioritization.  Of course included in that list was the stakeholder agreement model, which I mentioned above but included other alternatives for helping with prioritization. 

Value, Cost and Risk
Prioritize based on business benefit or cost savings for implementing the requirement.  This is a great way to get people re-focused on the “quick wins” for an organization.  By focusing on business value you depersonalize the discussion. The challenge is that business stakeholders may not have had the time to do an in depth analysis, or the background to feel comfortable with this model.   This model works extremely well with executives who are focused on these business analytics.

Regulatory Compliance
Requirements that are needed to pass a legal and or regulator agency should be given the same priority an organization has to meeting those requirements.  I’ve been in several discussions where just because a requirement met a condition for a regulatory compliance issue that alone pushed it to the top of the list.

Difficulty of Implementation and Likelihood of Success
These two criteria go somewhat hand in hand.  These methods allow the easy “wins” to be prioritized and for the project to gain some critical success and key visibility before deep diving into more difficult development areas.   This approach would enable stakeholders to become more familiar with early project results and provide critical feedback before going forward to build more difficult and possibly more expensive aspects.

Since reading this article, I’ve attempted to incorporate these other viewpoints into my requirements prioritization sessions with good success.  I have found that by using these different perspectives on when prioritizing the requirements can help break stalemates, and end political arguments.

In his book “Succeeding with Agile”, Mike Cohn present nine questions that you should ask for a current or proposed team. Questions should be asked iteratively… until you answer “yes” to each. Here are the questions:
* Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members?
* Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)?
* Does the structure maximize the amount of time that teams will remain together?
* Are component teams used only in limited and easily justifiable cases?
* Will you be able to feed most teams with two pizzas?
* Does the structure minimize the number of communication paths between teams?
* Does the structure encourage teams to communicate who wouldn’t otherwise do so?
* Does the design support a clear understanding of accountability?
* Did team members have input into the design of the team?

Besides the cultural bias (in Italy, one pizza will usually feed one person but it might be different in the USA…), you could use these questions for every project that you are currently running or plan to run.

Reference: “Succeeding with Agile”, Mike Cohn, Addison-Wesley, 262 pages, IBSN 978-0-321-57936-2

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

Here is a list of software development related conferences and events that will take place in September and that have media partnerships with Methods & Tools:

* Mobile Application Stores, September 7 2010, Zurich, Switerland

* iqnite 2010 Schweiz, September 21 2010, Zurich, Switzerland

* Lean & Kanban 2010 Europe, September 23-24 2010, Antwerp, Belgium

* Software Testing Analysis & Review Conference, September 26—October 1 2010, San Diego, USA

* iPhone/iPad DevCon, September 27-29 2010, San Diego, USA

* iqnite Nordic, September 29-30 2010, Stockholm, Sweden

* iqnite United Kingdom, October 4 2010, London, UK

* Agile Eastern Europe, October 8-9, Kyiv, Ukraine

Find more software development conferences

Our software development tools directory has now categorized more than 2000 tools. From project management and unit testing tools to NoSQL databases, you can find tools used in every software development activity, as the 10′000 monthly visitors do, searching by programming language, running platforms or another of our classification criteria.

If you are the committer of an open source project or the marketing manager of a commercial tool, do not hesitate to add your tool. It is free and you will be able to post press releases to communicate about new versions.

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

Last year, I wrote about my Lessons from a Bad Haircut.  I’m please to say I finally have a lesson from a good haircut.

 How did I finally get a good haircut? 

It was what the stylist did after I explained what I wanted.  She drew a quick sketch.  It took about 15 seconds.  And, with that sketch, I was able to say “No, that’s not what I want.”  60 seconds more of discussing what I wanted while pointing at the sketch, and she’d refined the sketch until both of us were confident that we were talking about the same thing.  The sketch was very crude and would never be confused with a work of art.  But, that wasn’t the purpose.  The purpose was to convey an idea.  And it did.  And, I got a good haircut.

So, what does this have to do with requirements?  

Most people relate to pictures much more easily than to words.  “Pictures” are all of the diagrams included in the RML®, such as process flows, wire frames, BDDs, etc. 

One of the major things to remember about creating these diagrams is that they don’t have to be perfect to be useful.  They simply have to be sufficient to convey the idea.  And, once a model of the idea is out there, the discussion becomes very productive.   If you can project the diagram or sketch it on a white board, people will point at it and discuss—what’s right?  How do we make fix what isn’t?  At the end the discussion, with an updated diagram, you’re ready to move forward with all parties confident they are headed down the same path.

When working with a client who wants me to skip the model and go straight to the words, I’ve found they react well to the statement “If we’re not in agreement about the model, we won’t get the words right.”  They get it:  it’s a matter of being more efficient and synching up our understanding as rapidly as possible, rather than wasting time on misunderstanding.

If I revert to my hair style of ten years ago–all one length and all I need is a trim–I can skip the sketch or picture.  Otherwise, a picture or sketch will be a prerequisite to any haircut I get.  I similarly recommend that requirements models be a prerequisite to any requirements you write.

Blog: Categorizing the Cloud …

Blog: Patterns and Practices for Improving Personal Productivity, Time Management, and Effectiveness

Blog: Earned Value v. Earned Schedule

Blog: A List of Coding Standard Websites

Blog: TDD at the System Scale

Site: Real QA Manifesto

Humour: My husband is a programmer; I have no idea what that means.

Article: jQuery Test-Driven Development

Article: Are We Headed to Abilene?

Tool: Flerry is a Flex-Java bridge for Adobe AIR 2.0

Tool: Coverlipse is an Eclipse plugin that visualizes the code coverage of JUnit Tests

Video: Managing Ruby Teams

Video: How to Cope with Communication Problems in an Agile Project?

Video: Continuous Integration, Pipelines and Deployment

Find more interesting links on the software development links directory, the software development tools directory, the software development articles directory, the software development blogs aggregator or the software development videos directory.

This is the typical response received when we suggest using a formal requirement management tool.

“Doesn’t MS Word provide enough functionality  to manage requirements? We’ve been using it and it’s worked fine for us so far.”

 It may be simple to jot ideas and start writing requirements in a Word document, or any other text editor, however, there are many limitations associated with using only one tool that is not designed to manage requirements.

These are the main limitations:

1) When making changes, it’s difficult to update and keep track of these changes,

2) It’s difficult to store extra information or additional detail about requirements, and

3) It’s difficult to link requirements to what is developed, tests, and defects. It is the goal of the requirements tool to provide a robust solution to managing requirements.

The following are some reasons to use requirements management tools.

Each tool you research should, at the minimum, be able to solve the following issues that a traditional text editor does not. The most obvious benefit is that with a tool, your requirements are all in one place: no more tracking down documents and trying to decipher which version to use, if your company uses versioning.

Ability to Manage Version and Changes

When business objectives change, requirements inevitably change. A requirements tool will keep track of changes implemented. It also becomes easy to revert back to previous versions, if necessary. Many people try to use SharePoint to distribute updates to documents. This can work, however, it’s easier to edit in real time in the same application rather than needed to put alerts on a document and checking it in and out. With a requirements management tool, people can work collaboratively in real time.

Store Attributes

Information, or attributes, concerning requirements should be associated with the requirement. This makes needing to remember what other document these attributes are stored moot. Additional examples of common attributes are author, person responsible, origin, priority, status, difficulty, stability, and risk.

Link requirements

It is necessary to link requirements to business decisions, emails, and conversations for traceability. It answers the question of “Where did this requirement come from?” and it also answers the question of “What other systems or element could potentially be affected?”. Also, being able to link requirements puts each team accountable for its actions. If, when you’re testing,  a test fails, it becomes convenient to link the requirement to the test to ensure that the team knows that the test should pass.

 Track Status

This helps to ascertain where the development team is on working each requirement, whether the requirement was deemed out of scope, etc. Being able to track status also provides a quick progress report for the project manager, or other responsible party. Status is an attribute of a requirement.

Control Access

If you’re working with teams across the state, country, or world, controlling access is a vital part of requirements management. You do not want someone editing requirements who should not be doing so and you want the ability to see a history of who edited which item.

Reporting

An additional benefit of a management tool is being able to better determine reporting and success measures.

 It does take time to determine which requirements tools would be the best solution for your company, and it does take time and effort to train users to ensure adoption, but those investments are worth the cost for better management and increased success. However, before starting your research, be sure to ensure your process of eliciting, developing, and reviewing requirements is effective, because a management tool will not help with the processes involved with developing requirements, it only helps with managing what you have.

This book is composed of papers previously written by Watts Humphrey. The people and management aspects of software development are often neglected in books and this one is a good source to start thinking about them… and improving our practice. The book is structured in four parts: managing your projects, managing your teams, managing your boss and managing yourself. In each part, it presents both general principles and real life examples or stories taken from Watts Humphrey career. This makes the book very easy to read as we can connect the theory to situations that we have met in our professional life.

Read the complete review on Sofware Development Books

Reference: “Reflections on Management – How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself”, Watts S. Humphrey and William R. Thomas Addison-Wesley, 260 pages, IBSN 978-0-321-71153-3

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team.  A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well.  However, unless you are at an executive level, there is very little you can do to shut down the black ops team.  In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built.  Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence.  However, once their presence is detected, a project and budgetary train wreck usually ensues.  

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place.  It’s probably because of one or more of the following reasons:

1. Low confidence that IT will be able to build something that actually solves a business problem.   Sometimes this low confidence is warranted.
2. No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it). 
3. Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it. 
4. Lack of understanding about why it takes so long to develop working software.

Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1. Keep the business engaged throughout the development lifecycle.  Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.
2. Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution.   Giving the business ownership of the process will help. 
3. Each project should have a clear ROI.  This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…”   People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem.   Just watch out for pencil-whipped  and contrived ROIs.  Be suspicious of any feature which does not tie back to a quantifiable business objective.
4. Use comparable projects to set expectations.  People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be.  This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”.  In order to head this off, it helps to show the budget, resources, and time to execute for similar projects.  It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?”  You can use the lessons learned on other projects to help answer this question. 

It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true.  Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.

One of my good friends recently changed jobs. For several years he was working with a fairly large software developer that loved to boast that they always had positive margins, always showed growth. I guess it isn’t too hard when you create nearly fixed cost products that can be resold over and over.

From my conversations with my friend I learned two things that I found very odd. The programs they created were never based on a researched business need or market analysis and none of the programming they did was based on documented requirements. Sometimes they created programs just because a sales person for a group said that he would buy it if someone made it. The worst of the stories involved having him program an add-in for an accounting software suite to integrate with an online sales platform. That doesn’t sound bad, except that they were going to charge for this add-in when the makers of the accounting software already offered the same product for free. I still can’t fathom how they weren’t losing money by just creating software for anything and everything, that they never made a business case for these programs. One of his ‘perks’ was that he had customer interaction by doubling as a customer support specialist for the software he created. Whenever he completed his sprint tasks ahead of time and was working with customers to fix bugs, he would get bored and ask them what they wanted the software to do. Then he coded it in. Otherwise, the customer’s needs never really got documented. However, he now works for a video game company here in Austin. A funny side story is that he actually had some fans of the company come up to him and ask if he worked for them and if he worked on their favorite game because of his company hat.

Several days into his employment he called me up and asked a few questions that made me chuckle.

 ”Hey, so what is this user story everyone is talking about?”, “Oh man we have a ton of meetings to decide what our programs do before we code them”, “So this is what you do? I love what you do!”, or “These wireframe things are awesome, I’ve never used them before!” The juxtaposition of his two roles is amazing.

Now when I relax on the weekend by playing a game or two I can’t help but think about all the requirements and documentation that went on in the background to make this piece of fun entertainment. Just like all the e-commerce websites, logistics systems, and loan originations software I have documented that was real serious business. Yup, even the game makers get it.

We invite you to propose a session for this leading software development conference. We have a long tradition of high quality sessions covering many aspects of software development, from programming languages (e.g., Java, C#, Python, Erlang, Haskell, Ruby, Groovy, C, C++, etc.), and technologies (libraries, frameworks, databases, etc.) to subjects about the wider development environment such as testing, architecture and design, development process, analysis, patterns, project management, and softer aspects such as team building, communication and leadership.

Sessions may be either tutorial-based, presentations of case studies, or take the form of interactive workshops. We are always open to novel formats, so please contact us with your idea. The standard length of a session is 90 minutes, with some exceptions. In order to allow less experienced speakers to speak at the conference without the pressure of filling a full 90 minutes, we reserve a number of shorter 45 minute sessions.

http://accu.org/index.php/conferences

Lately we have run into a number of projects that focus on reporting and analytics. As always our job is to determine the requirements. For analytics and reporting however, the requirements are a bit different than a traditional functional based portion of the system. We use a couple of different models, the report table, report flows, data dictionary and display action response (DAR) models.

The purpose of this post is to outline the steps we take to document requirements for analytics and reporting. A lot people we see doing this work  focus on the data in the reports. However this is a bit backwards. Instead, we focus on the business processes and the key decisions that are made from the reports. Ultimately the reports are used to make business decisions (even if those decisions are sometimes to do nothing) or to decide to take a specific action. Instead of focusing on fields,  we start with the business process and the decisions that the people using the reports need to make.

The problem with focusing on the fields is that it becomes very easy to group related information together, yet make it very hard for someone in the business to make their decision because they don’t have all the information that they need in a single location.  

Here is the process in a nutshell:

1) Define the business process - hopefully this is done as part of the overall requirements effort so you won’t need to do it for this portion of the project.

2) Define the decisions or actions that are being taken – often times these are the diamonds in the process flows.

3) Define the specific information that is required to make the decisions.

4) Design reports that support one or more decisions.

The key model that we use is called a report table. Included is the information that we collect to form our report table.

Fields in a report table

Reports are also linked in a variety of ways. We typically define a dashboard level which shows KPIs. KPIs are groupings of metrics and metrics consist of layers.

An example might be, a KPI of Growth which contains multiple metrics such as new customers and canceled customers. Within the metric of canceled customers there would be multiple layers of drill downs into more detailed information. Potentially the first layer is at a company level, the next level is a regional level, and then down to the level of viewing a breakdown of cancellations by cancel reason. The format we use is an excel spreadsheet with tabs (worksheets) for each metric. Within each tab are the fields as rows and the layers as columns.

Layout of a Report Table Spreadsheet

Google has recently bought Instantiations, the editor of Java, GWT, Struts and Ajax software development tools. On the Instantiations web site, the company says: “Yes it’s true. Instantiations’ award-winning Java and Ajax development tools and our incredible Eclipse team have been acquired by Google. We are all very excited about taking our technology and team to the next level – and there is no bigger step up than Google! We very much appreciate your patronage and interest through the years. As part of Google, we look forward to continuing to work with you. Please stay tuned for exciting new announcements coming soon on the Google Web Toolkit blog. Current Java and Ajax product customers — we are committed to making this a seamless transition for you. For a short period of time, new downloads of our products will be unavailable while we make the transition, but our service continues uninterrupted for those who have support agreements in place.”

The Smalltalk business will remain independent and their new web site is http://st.instantiations.com/. Mike Taylor will continue as President and CEO of the new Smalltalk-focused Instantiations. Founder Eric Clayberg will join Google, but will also continue as a Director/Board Member, technical advisor and major shareholder of Instantiations. John O’Keefe will assume an even stronger role guiding the technical development and advancement of VAST.

This acquisition is however not mentioned neither in Google Official Blog or Google Press Releases . On an Instantiations forum posting titled “Seamless migration to Google” , a customer complains that “Unless I’ve missed something the website is no longer available and the support emails just bounce back ? What am I doing wrong ?” It seems that the communication was lacking not only to the external world but also towards Instantiations customers. Mail to my instantiations.com contact is effectively bouncing…

I can understand that this acquisition may be a minor action in Google exciting life. For instance the press release section of Google doesn’t mention also that will stop deploying the Google Wave technology. This is what you call an “update” in PR language ;o)

Number 5 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”

1. Short-change Time Spent on Software Requirements or Don’t do Them at All
2. Don’t Listen to Your Customer’s Needs
3. Don’t use Models
4. Use Weasel Words
5. Don’t Prioritize Requirements
6. Don’t  Baseline and Change Control Requirements
7. Don’t do Requirements Traceability

 You have concise and unambiguous requirements, derived from multiple types of models giving multiple views, all based on accurate and thorough elicitation time spent with customer business and subject matter experts. Can you still shoot yourself in the foot before development starts? Absolutely! You have to build the right product before you can begin to build the product right. And building the right product must be done in the context of an ever changing business environment. Change happens.  It is a natural occurrence. It can be your friend or your enemy depending on your preparation. There are two main ways of dealing with change, requirements prioritization and change management. I will deal with the former in this blog and the latter in my next blog in this series.

 Why prioritize requirements?  Here is Karl Wiegers’ perspective from First Things First: Prioritizing Requirements:

“Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions. Establishing each chunk of functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements.

A project manager has to balance the project scope against the constraints of schedule, budget, staff resources, and quality goals. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers don’t differentiate their requirements by importance and urgency, the project manager must make these trade-off decisions. Because customers may not agree with the project manager’s decisions, they must indicate which requirements are critical and which can wait. Establish priorities early in the project, while you have more options available for achieving a successful project outcome.

It’s difficult enough to get one customer to decide which of his or her requirements are most important; gaining agreement among multiple customers with diverse expectations is even more challenging. People naturally have their own interests at heart and they aren’t always willing to compromise their needs for someone else’s benefit. However, making such priority decisions is one of the customer’s responsibilities in the customer-developer partnership.

Customers prioritize requirements initially from the perspective of how valuable each one is to them. Once a developer points out the cost, technical risk, or other trade-offs associated with a specific requirement, though, the customers might decide it isn’t as essential as they thought. The developers might also determine that certain lower priority functions should be implemented early on because of their impact on the product architecture. When setting priorities, you need to balance the business benefit that each function provides against its cost and any implications it has for the product’s architectural foundation future evolution.”

 One of the tenets of the agile project management process, Scrum, is delivering the highest value features to the customer first. This requires prioritization of requirements.

 There are several prioritization techniques. The best prioritization, regardless of the specific technique, will always rank software requirements according to a comprehensive set of business value attributes. The elements in the set and their relative importance will vary from customer to customer and over time.  Here are some possible business value attributes: NPV (Net Present Value), IRR (Internal Rate of Return), profit, market share, alignment to corporate strategy, competitive positioning, architectural positioning, internal or external strategic political objectives.

 Here are some common techniques. The light-weight techniques do not require a tool and are the most common. The medium-weight and heavy-weight techniques are most often used with a tool.

Technique Weight Light Medium Heavy MoSCow X     Prioritization Poker X      $100 Method (aka 100 Point) X     Cost Value X X   AHP   X X

 1.       MoSCoW

The capital letters in MoSCoW stand for:

• M – MUST have this.
• S – SHOULD have this if at all possible.
• C – COULD have this if it does not affect anything else.
• W – WON’T have this time but WOULD like in the future.

Explanation taken from Wikipedia entry for MoSCoW:

“All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the M, S and C requirements but the S and C requirements will be the first to go if the delivery timescale looks threatened.

The plain English meaning of the MoSCoW words has value in getting customers to understand what they are doing during prioritization in a way that other ways of attaching priority, like high, medium and low, do not.

Must have

Requirements labeled as MUST have to be included in the current delivery timebox in order for it to be a success. If even one MUST requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from MUST, by agreement with all relevant stakeholders; for example, when new requirements are deemed more important).

Should have

SHOULDrequirements are also critical to the success of the project, but are not necessary for delivery in the current delivery timebox. SHOULD requirements are as important as MUST, although SHOULDrequirements are often not as time-critical or have workarounds, allowing another way of satisfying the requirement, so can be held back until a future delivery timebox.

Could have

Requirements labeled as COULD are less critical and often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.

Won’t have (but Would like)

WON’T requirements are either the least-critical, lowest-payback items, or not appropriate at that time. As a result, WON’T requirements are not planned into the schedule for the delivery timebox. WON’Trequirements are either dropped or reconsidered for inclusion in later timeboxes. This, however doesn’t make them any less important.

Sometimes this is described simply as “Would like to have” in the future, this however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.”

 2.      Prioritization Poker

 A simpler variant of Planning Poker applied to software requirements prioritization. It is a consensus-based game technique. Playing cards are given to the stakeholders or their delegates and marked with Must/Should/Could/Won’t or a simple numerical ranking. A variation can include distributing the cards non-uniformly if some of the stakeholders have a greater say in the matter. A hand is played for each requirement (or group of requirements).

 3.      $100 (aka 100 point) Method

 This is another game-based technique. All stakeholders or their delegates have 100 dollars to spend on requirements that they would like in the release. They each “buy” the requirements they want up to $100 worth. The requirements are then ranked by how many total dollars the stakeholders wanted to pay.

  4.      Cost Value Method

 Each requirement is measured by 2 factors: a business value attribute and a cost to develop. For example, the business value attribute could be profit and could be ranked using the $100 Method and the cost to develop could be ranked with a high-level estimate of difficulty to implement and test. This high level estimate could be determined by Planning Poker, for example, or the formal Wide Band Delphi technique that it is based on. Cost Value Method can be done using an AHP tool for large, complex systems.

 5.      AHP (Analytic Hierarchy Process)

 The Analytic Hierarchy Process (AHP) is a structured technique for dealing with complex decisions. If applied to software requirements prioritization, the hierarchy represents a structured decomposition of the requirements from business objectives at the top to features in the middle to requirements at the bottom. There can be one or more hierarchies, each being a different view (e.g. profit, cost) of the requirements with its own business value attribute as the metric.  The total value of the system is determined. Each level must add up to that value and a parent node is the sum of its children.

 For example, in the diagram below, profit is the business value attribute with a projected total value of 25 million dollars. (Ctrl-Left Mouse on the diagram to view a larger copy in a new window). All level 2 (business objectives) sum to 25 million. All level 3 (features) sum to 25 million. All level 4 (requirements) sum to 25 million.

 

Software requirements prioritization helps the project team build the right product. It helps the team resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

For extra reading:

Karl Wiegers — First Things First: Prioritizing Requirements

Luke Hohmann – 3 part blog series (within Agile paradigm)

• Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
• Developing Attributes for Product Backlog Prioritization (Part 2 of 3)
• Prioritizing for Profit (Part 3 of 3)

Don’t shoot yourself in the foot on your next project! Resolve today to prioritize your software requirements by business value. The choice is yours.

Next time I will look at “Don’t Baseline and Change Control Requirements”

Seilevel Tweet

The valley of death between IT and information security
http://bit.ly/9OXx06