Posted by Ms. Melissa K. on Jan 14th, 2011 5:44pm
By Joy Beaty
ProductCamp and our Proposed Session on Cutting Project Scope
ProductCamp Austin is this Saturday – January 15. This is literally the first time I’ve been in town and available for a ProductCamp, so I’m pretty excited to attend. I have submitted a possible session to present at ProductCamp called “Using Business Objectives to Kill Scope and Launch Better Products”.

This topic is all about how you drastically cut the scope of products and still deliver a valuable product that your customers love. We use business objectives to ensure that every feature developed contributes measurable business value for the product. We want to show you how to develop good business objectives and then to apply those business objectives to cut the scope of the product. We do this using something we call Objective Factors, which attach dollar values to your features for comparison against one another. Ultimately you then select the features that add the most dollar value for development, delivering a valuable product for your customers.

If you are interested in the topic, put in a vote for our session and I’ll share the ideas and look forward to any feedback or suggestions you may have on how to do this!

Product Camp Austin

To read my other blogs.

Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Dec 20th, 2010 9:19am
Happy holidays from our SeiFamily to yours! We hope you can take a break from your holiday rush and enjoy some requirements tunes that are bound to make you smile! For more fun, sing along to our 2009, 2008, 2007, and 2006 songs.
Deck The Walls (remix)
Deck the walls with process flows
Fa-la-la-la-la, la-la-la-la
Check the trace matrix, all the rows
Fa-la-la-la-la, la-la-la-la
Now we make our system context
Fa-la-la-la-la, la-la-la-la
What a great start, now what is next
Fa-la-la-la-la, la-la-la-la
Complete it now, our state table
Fa-la-la, la-la-la, la-la-la.
Give each cell, a unique label
Fa-la-la-la-la, la-la-la-la.
Oh don’t forget your BDD
Fa-la-la-la-la, la-la-la-la
Next an org chart, it has to be
Fa-la-la-la-la, la-la-la-la
Dare we proceed without use case
Fa-la-la-la-la, la-la-la-la
No, no, they must fit in some place
Fa-la-la-la-la, la-la-la-la
Oh dear, what to do with data flow
Fa-la-la-la-la, la-la-la-la
In a diagram it will go
Fa-la-la-la-la, la-la-la-la
Make your data dictionary
Fa-la-la-la-la, la-la-la-la
All these models make me merry
Fa-la-la-la-la, la-la-la-la
Deck the walls with process flows
Fa-la-la-la-la, la-la-la-la
Use your models, spare all your woes
Fa-la-la-la-la, la-la-la-la
Jingle Bells (remix)
Release Bells, Release Bells
Prioritize all the way
Oh what fun it will be
To make our deadline day
Release Bells, Release Bells
Prioritize all the way
Oh what fun it will be
To make our deadline day
Dashing through the night
The ten man team will stay
O’er the code we go
Fearful all the way
Bells for release ring
Hoping it’s alright
What fun it is to laugh and sing
A success song tonight!
By JBeatty

Posted in Software Requirements, Business Analyst/ Product Manager, Requirements Models, Requirements Models 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Nov 22nd, 2010 1:39pm

Conclusion to 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

There are many ways to do serious damage to your project with poor software requirements. I have explored 7 of the most common ways over the last several blogs. It is time now time for a quiz!

1. A landmark study in the 1970s showed that an error created early in the project, for example during requirements specification, costs 50 to 1,000 times as much to correct late in the project as it does to correct (or avoid) close to the point where it was originally created. The author of this study was:
   a. Fred Brooks
   b. Ed Yourdon
   c. Tom DeMarco
   d. Barry Boehm
   e. Harlan Mills

2What are 2 reasons that errors are so much more costly to correct downstream?

3To prepare for a requirements elicitation session with your customer, you should:
   a. Prepare an agenda and distribute in advance of the meeting
   b. Distribute any review materials in advance of the meeting
   c. Know your audience well
   d. Show up early before the meeting to set up the environment
   e. All of the above

4. To show respect to your Customers and their time in a requirements elicitation session, which of the following should you not do?
   a. Manage time to the agenda
   b. Practice reactive listening
   c. Use models to abstract from lower level requirements complexity
   d. Elicit participation from all members
   e. Maintain eye contact and be aware of body language

5. To show respect to your Customers and their time after a requirements elicitation session, which of the following should you not do?
   a. Send out meeting minutes with decisions, action items and issues
   b. Send out meeting minutes the same day if possible
   c. Action items listed in meeting minutes should leave the due date blank so that the assigned owner can choose when to complete the task
   d. Plan to send out reminders to people with assigned action items

6. Which of the following is often cited as one of the classic positive examples of a company really listening to their customers and understanding their needs?
  a. Ford and Firestone  reaction to tire blowouts
  b. Toyota reaction to accelerator problems
  c. BP oil spill
  d. Johnson and Johnson  reaction to cyanide-laced Tylenol
  e. Airline customer service in general

7. Which of the following are good reasons to use models for software requirements analysis?
   a. Organize large amounts of information
   b. Figure out what’s missing
   c. Give context to a collection of details
   d. Focus on a particular subset of requirements
   e. Make it easier to find and fix requirements errors early
   f. All of the above

8. Which of the following are good best practices in the use of models?
   a. Don’t use them at all – it is better to go straight to the requirements
   b. Use only process flows
   c. Combine data flows and decisions trees with process flows all in one model
   d. Wait until after the requirements have been derived from the models before getting feedback on the models from the customer
   e. None of the above

9. Name some common types of requirements models to model the people aspects of the system.

10. Name some common types of requirements to model the system.

11. Name some common types of requirements to model data.

12. Using weasel words increases ambiguity in software requirements. True or false?

13. Which of the following requirements does not use weasel words?
   a. The system shall provide a best-in-class customer search capability.
   b. The system shall provide a robust data management compaction utility.
   c. The system shall provide flexible order entry.
   d. The system shall be fast.
   e. The system shall return the first 500 records that match the search criteria in no more than 2 seconds.
   f. The new GUI shall be user friendly.

14. One attribute of excellent requirements is that they are explicitly prioritized. True or False?

15. Prioritization of requirements helps project management to balance which of the following project demands?
   a. Schedule
   b. Budget
   c. Staff
   d. Resources
   e. Feature content
   f. Quality goals
   g. All of the above

16. Which of the following are not requirements prioritization techniques?
   a. MoSCow
   b. Prioritization Poker
   c. Prioritization Charades
   d. $100 Dollar or 100 Point method
   e. Cost Value
   f. AHP

17. Which of the following are symptoms of insufficient requirements change control?
   a. Unplanned  features become evident during testing
   b. New features requested after baseline requirements sign-off are not included in the final release
   c. Features that were rejected by the project team are implemented by developers
   d. All of the above

18. Which of the following do not support software requirements change control?
   a. Define a practical change control process for your project
   b. Use a CCB
   c. Establish and enforce realistic change control policies
   d. Delegate addition of last minute cool stuff to the discretion of marketing and development staff
   e. Use a tool to collect, track and communicate changes

19. Software requirements traceability is required in the medical device and aerospace industries. Is it still valuable for other software systems even if their failure does not lead to loss of life?  Yes or No.

20. Which of the following questions are answered by requirements traceability?
   a. Is every business requirement covered by at least one functional requirement?
   b. Are there any functional requirements that do not support a business requirement?
   c. Are the highest priority requirements being implemented first?
   d. Which requirements are not yet tested?
   e. Have all requirements been successfully tested?
   f. All of the above


1-d, 2- project artifacts to be corrected increase over time and more people need to get involved in defect correction as the life cycle progresses, 3-e,  4-b, 5-c, 6-d, 7-f, 8-e, 9-org chart, use case, user stories, decision trees; 10-context diagram, cross functional process flow, UI display-action-response table, wireframe; 11-business data diagram, data flow diagram, state diagram and state table, data dictionary; 12-True, 13-e, 14-True, 15-g, 16-c, 17-d, 18-d, 19-Yes, 20-f

How did you do?


Don’t shoot yourself in the foot on your next project! Resolve today to use good software requirements skills to help put your project on the road to build the right product and build it right. The choice is yours.

Posted in Software Requirements, Business Analyst/ Product Manager, Requirements Models, Requirements Models 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Nov 11th, 2010 4:46pm

We look for the best and brightest when hiring for Requirements Analysts and Product Managers. It’s a long and difficult process with many people applying; only a fraction get through the first interview and even less are able to hang in the process as it continues. This has brought great strain to our company: as we expand we simply aren’t able to hire as very few are able to get through our arduous interview process.

Recently, we went to the University of Texas at Austin looking for interns and entry level Requirements Analysts. They asked many questions, mostly along the lines of “what does Seilevel do?”, “what would a typical day look like for me as an RA?”, “what’s the mentoring program like?”, and “what qualities do you look for in a potential new hire?”.  I would like to address the last question now, to give the potential candidates out there an idea of what kind of person we look for.

Most importantly, we look for those in whom we see great potential. Can we teach and train this person? Will she be receptive? Is she able to adapt and change to the ambiguous and sometimes difficult environment? Is she smart enough to resolve tasks on her own when others are too busy to hand-hold? To get an outstanding “Yes” on all these questions is the first test to pass. When we talk to people, we want to address these questions indirectly with candidates. This means that we most likely won’t ask these questions in the form as written above, but we probe to elicit answers which give clarity to the aforementioned questions.

People are smart. Sometimes, we want to give a solution to a problem so badly that we neglect to listen to the entire problem. We look for candidates that are patient enough to listen to a whole problem before recommending a solution. As consultants, our clients look to us to solve their problems, so it’s very important that we all know how to listen. Good listening skills include maintaining good eye contact, maintaining attentive posture, and being able to summarize the problem with different words to show you understand what the issue at hand is which also uncovers underlying assumptions.

Gathering requirements includes many hours of asking probing questions to the business in order to gain a clear understanding of what the product needs to do. We want people who instinctively ask the right questions. This is a hard item to teach, so we are looking for those who have the critical thinking skills which enables them to have these types of constructive dialogues.

We want someone who works well under pressure. From school, you’re hopefully used to completing projects or papers with strict deadlines and occasionally working long hours to ensure you get that paper or project perfected. Oftentimes on a client site you will encounter strict deadlines, as each man hour over a deadline is quite costly. We’re looking for those Type-A personalities who know what it takes to get the job done well.

Many people who are Type-A and direct communicators can be considered abrasive. What’s the difference between being a direct communicator and being abrasive? We look for those who can communicate with all kinds of people without offending them, which entails being able to change how you say things to suit the recipient. In the US, if a topic is misunderstood or lost in communication, it’s the speaker’s fault, not the listener’s.  We look for candidates who grasp this concept. These people can explain the same topic using different words or methods, which better suits the listener.

Prioritization is a must have. When you have a paper for English, a SWOT analysis for marketing, a business review for accounting, and a program for comp sci all due in the same month, what do you do? How do you prioritize? What comes first and why? We always have several hands pulling at our limbs, asking for time in meetings, reviews, documentation, etc. Getting it all done and ensuring client happiness is a delicate art.

My last tip for the day is to ooze confidence! Can you present in front of a room of 20 executives and the CEO? Probably not.  (And it may not be a worry here, either!) However, you should be able to speak your intelligent and prepared opinion in a meeting with stakeholders. Don’t be afraid to speak up, with a caveat: as long as you know what you’re talking about. (However, you can always talk it over with another consultant if you are nervous!) As consultants, clients look towards us for answers. We need to study the issue and propose a solution, often on topics in which we may not have formal training, but our logic can trump that issue.

Many of these skills are difficult to teach someone, which is why we look for the candidate who is the right “fit”, meaning that they already possess these baseline soft skills which we can then build upon with requirements knowledge. When preparing to interview, be sure to have prepared situations that you have personally experienced which would demonstrate your capacity to fill these characteristics we look for.  Look for Part II of this post next month where we will discuss critical thinking skills necessary to become part of our team.

For part here.

By Kdicenso

Posted in Business Analyst/ Product Manager 1 Comments | Link to this Post
Posted by Ms. Melissa K. on Oct 28th, 2010 4:06pm

My fellow Seilevel bloggers have written about the many virtues of Org Charts and their relationship to requirements elicitation and management.  In case you missed it, here is a good summary of an org chart and how to use one in requirements gathering.  To help catch you up to speed, an org chart is one of the first requirements activities you should engage in at the beginning of the project (or even when you join a project in the middle or end).  Briefly, the org chart should be used to:

  • Identify Key Project Stakeholders
  • Identify Actors in Use Cases
  • Delineate project roles and responsibilities.

In other words, the org chart drives many of the other requirements-related project activities. I’d like to talk about another, little-known use for an org chart–navigating project politics.  Like it or not, politics are a part of any project, and successfully navigating project politics can mean the difference between project success and failure (Note that I did not say “playing project politics”.  This is an entirely different matter altogether and a skill that I don’t recommend fostering).  Unfortunately, there are few formal tools at the Product Manager’s disposal for recognizing political risks and avoiding political disasters before they happen. Typically, when projects are overly political, “navigating project politics” is an exercise in damage control rather than avoiding politically dicey situations to begin with.

The nice thing about using an org chart to help identify and manage the political realities of your project is that they are fairly simple to create and maintain, and it is easy to hand off to other team members.  Additionally, an org chart should already exist on your project, so to create a Political Org Chart is just a matter of adding supplemental formatting to your project org chart.

It’s best to use an example to illustrate how to convert a standard org chart into one which bounds political realities.  Consider the following org chart which displays a typical top-down hierarchical organizational structure.  Such an org chart is useful for identifying key stakeholders, reporting structure, and areas of expertise.

For the Org chart please click here for the rest of our blog.

 By Jhulgan

Posted in Software Requirements, Business Analyst/ Product Manager, Requirements Models, Requirements Models 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Oct 20th, 2010 1:44pm

We are delivering train-the-trainers sessions to one of our customers. In these sessions, we are training some of their senior Business Analysts (BAs) on how to give our Requirements Elicitation course to other BAs in their organization. Well, this week I was working with two people in Houston, two in London, and one in the Netherlands, and I was reminded that with global audiences we have to be careful with our language choices!

The course was originally developed with an American audience in mind. And for the most part, the course will work for global audiences as well. However, it seems we needed a few tweaks in the language on the slides and in the delivery. I was talking about how to deal with angry stakeholders and one of the steps is “Know when to bail”. When I wrote this and explained it, I meant, “know when to disengage from the conversation with the angry stakeholder in a non-rude fashion, by suggesting you will take it offline”. Well, one of the global participants from London had never heard the phrase “bail” in this context alone (he knew “bail out” but not just “bail”) and had to stop me to ask me to explain. The funny part was when the guy from the Netherlands chimed in to say he knew the phrase quite well, suggesting  it must be a British language thing, nothing how we were getting tripped up on a common language.

So to further complicate the issue, I went on to explain it with other phrasing and I said that in these difficult conversations with angry stakeholders, you made decide to “table it”.  Well, I was caught again. Apparently the phrase “table it” means two different things depending where you are. While in my case, I meant “to drop the topic for now and revisit later”, the phrase “table it” in other parts of the world means “talk about it now”. Can you imagine the confusion if you try to “table it” and half the group keeps talking about it while the other half tries to move on?

So this is just a fantastic reminder that you must be careful about your word choices when working with global stakeholders. Their English may be fantastic, but try not to use jargon so you can avoid frustrating them!

By JBeatty

For more check out our blog

Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Sep 26th, 2010 4:11pm

Are you attending REET’10 or RE’10 in Sydney Australia?

If you are going to either of these Requirements Engineering speaking engagements don’t miss out on another event.

The Sydney DAMA chapter is hosting Joy Beatty and she is presenting:

 Visualization using RML®: A Practical Suite of Requirements Models

Seilevel is a professional services company based in Austin, Texas, focused exclusively on software requirements. The Seilevel mission is simple: to revolutionize the way companies create software requirements. This presentation provides an overview of Seilevel’s Requirements Modeling Language (RML®), a language specifically developed for modelling software requirements. While many formal modeling languages are rich in capability, they are also very challenging to roll out as general practice in industry organizations because they are complex. RML® is the bundling of common requirements models into a language that is pragmatic for anyone to learn and use.

Each model is designed to be the most simple it can be while conveying the necessary information about requirements. This enables all levels of practitioners to create them and all business experts and developers to read them easily. The use of these models helps scale requirements to many expertise levels in the organization. The presentation is targeted at practitioners whose job includes eliciting and documenting requirements. It will cover an explanation of a handful of the models (ex. context diagrams, state tables, display-action-response tables, etc.), how they enable and are used in the requirements process, the relationships between the various models, and how to select which models to use in any given situation...

For more information:


Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Sep 20th, 2010 8:02pm

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?

Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 24th, 2010 5:54pm

Do you really love writing requirements?  This is the place for you! 

At Seilevel we are serious about requirements and designing software. Our mission is to redefine the way companies create software requirements. Due to our high level of customer referenceability we have a tremendous backlog of work and need to expand our staff.

We are looking for people who:
• love to take a project from business case to deployment
• want to make requirements facilitation and review sessions fun
• are excited to learn completely new subject matter areas within days of joining a project
• have a history of making clients referenceable
• can write requirements documents that are thorough and complete but also understandable
• really understand how to prioritize requirements
• want to research the field of requirements and write articles and papers
• will establish strong relationships with client contacts at all levels

To check out the full job description:

To apply send your resume to

 You can also check out our blog at:


Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 22nd, 2010 8:19pm

We’ve written a few blog posts about how to be a sucessful Business Analyst. Such as 12 Things to Fertilize Your Business Analysis Career  Plus there’s other sites that have helpful information on the subject how to become a Business Analyst, and how to be successful.

But people often ask; what do we look for in a BA?

One of our biggest challenges is finding good Business Analysts and Product Managers. We interview a wide variety of individuals but it’s really tough to find good hires. Since we specialize in such a detailed field we really have to look for specific skills. Having relevant experience and having consulting experience does not suffice.

Our interview processes is also a bit more unusual than most companies. We start off by having the candidate fill out a questionnaire, we conduct a phone interview. Then we have two onsite interviews that are more specific to job required skills for the business analyst and product management job.

This process is more thorough than most; however we feel we can get a better feel for the candidates’ background and culture fit by doing these series of evaluations.

During this whole process we look for certain skills at each step. If a candidate does poorly at any of these steps, we won’t move him/her on though the remainder of the process.

All throughout the interview process we ask ourselves:

Do they have strong analytical skills?
Have they written software requirements documents before?
Are they detail oriented?
Are they a good cultural fit?
Do they have any consulting experience?
Are they coachable/ trainable?
Are they personable?
Are they professional?
Would I like to work with this person?

Answering ‘yes’ to all of these is a rare find.
Most important to us: we have to have BA’s and Product Managers who possess strong analytical skills, are very detail oriented, solid technical skills and are someone we would like to work with.

Want to read more?

check out our blog here.

Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 12th, 2010 4:14pm

As consultants and product managers, it is important that we quickly build and maintain credibility with our team so that we can work productively and effectively.   If you are unable to join the team dynamics, the work that we provide will be met with apathy or even outright hostility.  I’ve learned a few tips to help establish credibility quickly.  

Maintain your visibility –  Initially, it is important to get plugged into as many face-to-face meetings and conversations as possible.  By being face-to-face it gives you the availability to learn more about the project right away, gives you context, and you will quickly meet many of the people who might influence your efforts.  Your team can see you demonstrating your expertise and learning about the challenges of the project. They will see you as a member of the group.  If you are not able to join many meetings, just being onsite and visible  will help establish your presence. 

Learn about your customer and your team -   Knowing the business issues and pain points of the project team will help establish your credibility.  Research the business and the challenges before meeting with your team.  Usually, you will have a point of contact within the organization who can share the current challenges, and possibly some of the team dynamics.  It’s also important to keep an open mind when learning about a new group.  Everyone has a perspective and until you can gather your own impressions, take what’s shared with you with a grain of salt.

Be Personable – It is critical to try to establish a personal relationship beyond the necessary professional one.  I’ve found that if a new team member can connect with me on a personal level; it goes a long way towards smoothing out the edges professionally.  Try to ask your team members about appropriate things that matter to them, like kids, interests or holiday plans.  If you do ask, be sure to remember what they told you and be genuinely interested.  If you do ask about a team member’s personal interests – Don’t forget the answers.  Even if you have to jot them down on a notepad to remember later. It’s critical that you not ask the same personal question twice.  People may give you a pass if you repeatedly ask the same question about work related topics, but if they care enough to give you an answer about something personal, you should care enough to remember it.

Be a good communicator and listener – The ability to communicate effectively and sincerely will always enhance your ability to establish credibility.  It’s important to be engaging, and build professional relationships.  Effective communication can quickly build a personal rapport between you and the other team members. 

Never let ‘em see you sweat –  This is hard to do in practice but important.  If a person is going to have faith or confidence in your ability to get the job done, then you should have faith in yourself.  Issues and problems will come up from time to time, but having grace under pressure allows people to feel comfortable that you are the part of the solution and not part of the problem.

Do you have tips? Let us know.

By LAnderson

Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 9th, 2010 1:34pm

Do you know who your audience is for your software requirements? Why, it’s the development organization, of course! And while that is true, development is the main audience for software requirements, there are many other audience members as well.

1. Testing Team. I am sure that most of you also thought of the testing team as another audience for software requirements. The software requirements give the test team a baseline from which to write their test plan, test cases and test scripts. The test team looks not only to see if the software works, but does it work the way the user wants it to work, according to the software requirements. You may also find that your test team is an excellent group to review your software requirements for clarity. They tend to look at software requirements from a perspective of “how would I test that requirement?” If they cannot think of a way to test the software requirement, the software requirement may not be clear and/or concise.

2. End Users. What about the end user? Those who are communicating what their needs are, of which the software requirements are intended to capture? They are also an audience for your software requirements. We need their reviews to make sure we have documented their needs clearly and accurately.

3. Technical Writing. Technical writing is another group that relies on software requirements for their work. We all hope that the Help content of the product reflects what the software does, the best place for the technical writing team to get that information starts with the software requirements. Of course they will also confirm their content with the software itself, but they can certainly get started with the software requirements.

4. Translation Teams. Translation teams also rely on software requirements to help them understand what the product is supposed to do, so they can translate not only the software but also the technical documentation appropriately for their language and culture.

5. Training. Organizations that develop training courses for the software also rely on the software requirements. Like many groups, the software requirements help the training department plan and structure their curriculum, so they can develop and deliver courses quickly and that are ready for training the end users when the software is implemented.

6. Support Organizations. Support organizations, both internal help desks and product support groups that take the front line calls from customers also use the software requirements to help trouble shoot issues reported. By looking at the software requirements, Support can help determine if the issue reported is a flaw in the software, or if it is working as intended.

7. IT. Internal IT groups are also interested in software requirements. Beyond the technical requirements for hardware, software, etc that will be required to support the software, IT groups also want to understand any interfaces to other existing software that must be built. They need to understand the support requirements of the software, what sort of administrative tasks will be required of them.

8. Consulting. If you are working in a commercial software environment, your consulting organization would also be an audience for your software requirements. They need to understand the new software that is soon to be released, so they can plan implementation or migration services for your customers.

There are lots of audiences, make sure you are including them all when you design the format/layout and include them in all the appropriate review meetings.

by Bstockdale

Want more? check us out here.

Posted in Software Requirements 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 9th, 2010 1:31pm

Design has never been one of my strong points.  When I was picking out paint for my new home I assumed that if I liked the color, then it would work on the wall.  Didn’t turn out to be true.  Same goes for my requirements.  Just because my mock-up screen had a cornflower blue tint doesn’t mean that was a functional requirement.

 I know that these fields must be included during registration.  I know the impact to the business if they are not there.  I know what they allow for length, as options, and as valid data input.  I know the errors that must occur when they aren’t used properly.  I know the actions that occur when a user selects one option over another.   I know what the maximum acceptable response time is and how many results should be presented at any given time.  I know what information should be contained in a report.  I know what information should be summarized in graphical forms.  These are my realm.  These are my expertise.

I do not know the difference between Calibri, Arial, or Helvetica let alone how it will influence a user’s experience with a tool.  I have limited knowledge on where the user focuses their attention fist when they see a screen.  I do not know the best way to present information gathering forms.  I simply can’t fathom the correct way to space and arrange information to make it a great example of form and function.  I don’t know how the error should be presented to the user.  I do not know the best way to create a graph to quickly and accurately convey the needed information to the consumer.  These are at best my hobby.  These are a mystery.

Discussing the proper way to create infographics or design pages for ease of use sound like a great way to spend some time.  While I find these things interesting, these certainly are not my specialty and I don’t keep up to date on the new best practices.  I listed a small fraction of things that show up on my radar for requirements that a designer wouldn’t think about and I also listed a fraction of things that I am aware of for designing tools.  My knowledge comes from some brief ventures into reporting and an interesting person named Edward Tufte. This is his site.

I fear each time I present my documentation that a mock up or screen shot will be used in development as the model of record.  Alternatively I fear when development is free to implement the design as each individual sees fit.  I fear these things because it creates Frankenstein user interfaces.  They may be ‘alive’, but the users tend not to accept them very well.

I advocate the use of designers (web, UI, or otherwise) as it does make a huge impact.  It can influence user adoption, user dropout, user community, learning curve, understanding of business data, and a slew of other items.  Keeping the tools with the same feel creates branding and familiarity. 

The MSN User Experience Team developed new user-centered methods to provide structured user input on the visual design of the newly-released MSN Explorer, an integrated software package. In the final product, users rated “appearance” above all of the product’s features. “  Many organizations and people devote enormous effort into getting design right and when the budget and timeline allows, it should be kept separate from the requirements.

This is Don Norman and a link to his site is here.

To read our others posts check us out here.

Posted in Software Requirements 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 9th, 2010 1:28pm

At the beginning of almost every project (and even sometimes midway through them) we are asked to create a requirements plan and estimate the time required on tasks and the number of BAs necessary to execute it. In a later post I’ll talk about the actual plan items, but we do have a rule of thumb for how many BAs you need on a project.

We have a standard metric we use: we suggest 1 BA can support 4 to 8 developers. Typically I suggest 1 BA to support 4 to 6 developers though, as 8 is a stretch on many projects. Of course this number is highly dependent on the context of your project, so treat it as a rule of thumb only.

As an example, right now we have 7 developers working on rebuilding existing functionality from an existing site and it’s required just over 1 BA to work on the requirements for it. And even at that, the BA is pretty stretched to get them done as fast as the dev team needs them. And in another part of the project, we have 1.5 BAs supporting about 4 developers who are doing defect testing – but they are also very intensely focused on UAT activities.

Want to check out other blog posts?


Posted in Software Requirements, Business Analyst/ Product Manager 0 Comments | Link to this Post
Posted by Ms. Melissa K. on Aug 9th, 2010 1:24pm

On a recent client’s project, we were asked to help in the effort of creating a system to automate much of the current manual processes.  In order to capture the requirements this also meant that we were documenting the business rules that were currently being used.  When I started the project, I did not have a complete understanding of how a business rule was different than a requirement statement.  I found that I was constantly getting mired in my confusion between the two. 

From my research I did find one Wikipedia article to be particularly helpful, but I simplified that advice even further.  From my reading  and experiences, I created the following four guidelines to help me determine if a statement was a business rule that would need to be represented within the new system and should described within my functional requirement statements. 

 1:  A business rule is about the how to run the business and not about a system, or set of systems.  If you removed all the systems and system platforms, the rule would still important to the business operations.  Business rules are about people doing business activities, to achieve business goals not interacting with systems.  A very simple rule that is used every day is “No shoes, no shirt, no service” a person can read this rule, and know what actions they are to perform.  A functional requirement would be to support the “No shoes, no shirt, no service” rule within the system.

2: Does the rule provide enough information for a business person to make a decision, or a series of decisions?  If a business person uses the rule to make a decision, then it’s a business rule.  The rule exists in order to operate the business.  A business person could easily read the rule and understand how they are to conduct business.

3:  Business rules are owned by the business.  A business person must be able to change, or modify rules as they identify changes.  For example, a rule may be that “Only people between the ages of 25-35 may open a customer account”.  A system requirement could be written to support that age constraint.  The rule however, is owned by the business and could be changed at any time based on business objectives. 

4:  A business rule must place some type of constraint or requirement on the way that business is conducted.  For example, “Only customers with an approved line of credit of $1,000 or more may place orders within the corporate product catalog”.  This rule shows how customers are constrained and prevented from certain operation, or activities.  A system requirement might be necessary to support multiple rules which constrain customer activities.  The business rules define the constraints.

 Do you have feedback on how to determine a business rule? Check out our blog here.

Posted in Software Requirements 0 Comments | Link to this Post
version 2.33.8 ::
Desktop View