Category Archives: Tips for Business Analysts

The Starter Project Business Analyst – a job description

Author: Geri Schneider Winters

You may have just finished college, or have none of the skills needed for a more advanced BA role. You are interested in a Starter Project BA position either to learn more about the job to see if it is something of interest, or because you have decided on this as a career.

All Business Analysts use the skills of the Starter Project BA. Even if you end up starting as a Mid-Range Project Business Analyst, you will still need the skills of the Starter Project Business Analyst. There are a lot of projects where you will be the only BA, so you will have to have the skill set of all three levels of Business Analyst. The Starter Project BA skills are also very useful or required in a wide variety of jobs.

If you are a Starter Project Business Analyst you work on a project team. This could be a software project, a business process improvement project, or many other kinds of projects. You are responsible for collecting information and communicating it to the appropriate team members.

Like a Ham (Amateur) Radio Operator on an emergency response team, your specialty is Communications. You need to be good at finding all kinds of information by researching in documentation of all kinds and by eliciting it from people. You also need to be good at sharing the information in a wide variety of formats and technologies.

As a Starter Project BA, you need to be comfortable with a wide variety of people and situations. You should not hesitate to make a telephone call, send an email, or instant message any one from whom you need to elicit information. You need to be good at setting up meetings, taking notes, and following up on action items. You should be comfortable talking to people one-on-one, as well as comfortable facilitating a meeting.

You do not need to be an expert at every possible form of communication before progressing to a Mid-Range Project Business Analyst. But the more comfortable you are with a wide variety of people and technologies, the better you will be at any BA role.

As a Starter Project BA, you are not expected to work alone. A more senior BA, Project Manager, or BA Manager will direct your work. He or she will also mentor you to develop more BA skills.

The most important skills for a Starter Project BA are:
• Listening
• Scribing
• Facilitating
• Holding interviews
• Research, both online and in documentation
• Writing

Technologies you should master are:
• Email
• Instant Messenger
• Telephone and VOIP
• Standard office software
• Digital Recorder
• Projector and computer for meetings
• Teleconferencing System

The most important personal traits are:
• Warm and friendly personality
• Comfortable with all kinds of people
• Comfortable in all kinds of situations
• Self-motivated
• Organized

 

The Importance of the Job Description

Author: Geri Schneider Winters

You have been thinking of becoming a Business Analyst, and are not sure how to go about it. Since few people leave college and start working as a Business Analyst, you are probably making a career change, or at least are looking for a way to move from a related role into a Business Analyst role.

Everything starts with a job description. You have to know what you are looking for in order to find it. I think the area of career development for Business Analysts is a bit difficult because the career path is not well defined. There are efforts to define the role – Prince 2 and CBAP – but I don’t think there is widespread agreement throughout the industry yet on really what is meant by Business Analysis. I do have specific suggestions on a Business Analyst career path, including how someone might become a Business Analyst directly after college.

I used to think that a person should work 3-5 years before becoming a Business Analyst. I realized that I was only thinking of a Senior Business Analyst. That is one of the problems currently facing Business Analysts, that we do not have defined levels. So I have defined a useful progression of Business Analyst roles.

I created these job descriptions based on my own experiences as a Business Analyst, Project Manager, and leader of a team of Business Analysts on very large and huge projects. I have asked other people with backgrounds as Business Analyst and various kinds of managers to review these descriptions. They all agree that this is a useful and reasonable approach to a Business Analyst career path.

In defining a series of Business Analyst roles, I had several goals to achieve. First, each position I described had to be useful to a company and project team. Second, there had to be a clear increase in responsibility from one role to the next. Finally, I wanted to be very precise in the descriptions so that you can take them to hiring managers, and the hiring managers can see the usefulness of the work for their teams.

While reviewing the work of very senior project Business Analysts, I determined three clear, useful roles for a Business Analyst to play on a project team. These roles are: Starter Project Business Analyst, Mid-range Project Business Analyst, and Senior Project Business Analyst. There are many other jobs that a person called a Business Analyst can do. In this and succeeding articles, I have outlined the project BA roles because I believe these are the most common roles for a BA.

If you do not have work experience, you will begin as a Starter (or Junior) Business Analyst. If you are making a career change, you will probably be able to start in a Mid-range or possibly even Senior Business Analyst role.

The first step in looking for a Business Analyst position is to look at descriptions of different levels of Business Analyst to see where you fit in terms of your skills and experience. Then you can take the appropriate description to a hiring manager and explain to them that this is the job you want to do. If you do not yet have the necessary skills and experience, then you can use the descriptions to determine where you need further education and experience.

 

Intro to Finding a BA position

Author: Geri Schneider Winters

I get a lot of emails and blog posts from people who want to be Business Analysts, but are not sure how to go about finding a BA position. This article is the first in a series discussing techniques for finding a BA position.

One of the issues all Business Analysts face is that the role is poorly defined. There are efforts to define the role – Prince 2 and CBAP – but I don’t think there is widespread agreement throughout the industry yet on really what is meant by Business Analysis.

In other articles on this site, you will see that I have defined a progression of BA roles. You can look at the pages for Starter Project BA, Mid-range Project BA, and Senior Project BA for descriptions of those roles. Having these descriptions in hand will make it easier for you to talk with a hiring manager about what he or she thinks a Business Analyst is. They will also help you communicate how you can bring benefit to the project team or company.

You need to think about whether you are changing jobs within your current company or looking outside your company. The techniques are quite different in these two kinds of job search.

If you are looking outside your company, the first obvious step is to apply to job ads. This does not work for me, nor have I known it work for many other people. In fact, a friend told me about some research where the best people in a company were asked to put a different name on their resume and send it to their own human resources department in response to some job ads. This was to see the effectiveness of applying to job ads. Not one of those people was offered an interview!

The basic reason is that the people in human resources get a lot of resumes in response to job ads, so they use automated tools to do keyword matching. If the tools do not find the right keywords in your resume, then it is rejected. If your resume is rejected, very often no human has even looked at it.

The next technique you may try is working with a recruiter. A lot of BA positions are only advertised through recruiters. If you find a good recruiter, that person will understand the position you are applying for and will be working closely with the hiring manager. If you do not find a good recruiter, your results will be the same as applying to human resources through a job ad.

In this series of articles, I outline some other strategies for looking for a job outside your company and inside your company. These techniques include networking, direct marketing, and creating a transition plan.

If you try out some of those techniques, post your results on this blog. If you know another way to find work, post that as well, so we can all learn more ways to effectively look for a job.

 

Using Teleseminars to Communicate with Distributed Teams

Author: Geri Schneider Winters

As a Business Analyst, we are often in the role of facilitating discussions among stakeholders. There is also a need to give presentations. You may find a need to teach something to the stakeholders, for example, a quick introduction to how to use IBM Rational Requisite Pro on the project.  You may be asked to demonstrate the software being developed to groups of people throughout the project. While a requirements elicitation session is a discussion, a requirements review session should be a presentation. When your project team is geographically distributed, you can give presentations by teleseminar, webinar, or a combination of the two.

First, I need to define some terms so you know what I am talking about.

  • Teleconference – a meeting of a group of people using the telephone, where items of business are discussed among the participants. Anyone can talk to anyone else in the meeting. The meeting should be facilitated.
  • Teleseminar – an audio presentation by a leader to a group of people using the telephone. This may include the ability for participants to ask questions. It is not a discussion among participants, but a dialogue between the participants and the leader.
  • Telewebcast – an audio presentation by a leader to a group of people using telephone and webcast software in a web browser.
  • Webinar – webcast software plus the ability to show visuals.

This article addresses Teleseminars and Telewebcasts. I will just call them teleseminars in this article.

Like any other meeting, the teleseminar has a topic or agenda, a list of participants, a date, and time of meeting. Unlike other meetings, you do not have to schedule a meeting room, since each person will attend from his or her own workspace. Be sure that the meeting you are scheduling is a presentation, not a discussion. The two kinds of meetings are managed differently.

First, find out what software your company has available for you to use. Is there a bridge line or conference call service that you can use for the meeting? Do you have webcast software such as Instant Presenter, or Instant Teleseminar? If you will be demonstrating software, you will need full webinar software such as WebEx, Go To Meeting, or Live Meeting to be able to share your desktop with participants.

The better services offer a control panel to the leader which lets you see who is online, mute and unmute individual people, and has a way for participants to indicate when they have a question.

Second, you will schedule the meeting using the appropriate service, then send out an email to participants telling them what the meeting is about, what day and time it is, and exactly how to participate. Giving complete instructions makes it more likely that everyone will successfully join the meeting. I like to send out a reminder the day before the meeting, and another reminder a couple of hours before the meeting. These reminder messages can be copies of the original meeting notice.

Some of the participants may want to schedule a conference room and attend by speakerphone. I do not recommend this approach. It is very hard for the people in the conference room to hear, and almost impossible for anyone else to understand people in the conference room. If you are holding the meeting by telewebcast, it is even more difficult for a group of people to participate by looking at one computer. Encourage each participant to attend the meeting from his or her own workspace.

Finally, the time has arrived for the teleseminar. As a leader, you should call in at least 5 minutes before the scheduled start time. If the meeting will be recorded, you can start the recorder at this time. Greet participants as they arrive to the call.

In general, you will want to mute all participants while you are presenting. Allow some time for questions. You can schedule all the questions for the end of the call, or stop presenting periodically and unmute the lines for questions.  Some of the telewebcast services have a web interface where a person can submit questions. Then the leader sees the questions on a control panel. This is a very nice feature, because it allows the participants to ask questions when they occur, and allows you to schedule in the answers as part of your presentation.

If you find it too difficult to present and monitor participants at the same time, then you might have a co-leader for the meeting. You just focus on making the presentation, the co-leader watches for questions, and makes sure you are allowing time to answer them.

Another great option is to ask for questions before the meeting. You can use those questions to prepare your material for presentation.

At the end of the meeting, be sure to thank everyone for attending. If you are recording the call, let the participants know where the recording can be found. Review any action items. It is polite to unmute the lines for everyone to say goodbye. Then stop the recording and end the call.

 

Starting, mid-range, and Senior Business Analysts

Author: Geri Schneider Winters

I have been thinking a lot recently about what I would expect if I were hiring a Business Analyst.  My expectations are very different if the person is a starting Business Analyst, or someone with a few years experience, or someone very senior.

For a starting Business Analyst, I would expect the person to be able to elicit, organize, and verify information with the project stakeholders. Notice I do not say to elicit requirements, but rather to elicit information. I think it takes more experience to be able to determine what the actual requirements are, and this requires a person to be skilled in analysis techniques. The starting Business Analyst should have strong communication skills – listening, speaking, and writing – with people who have a wide variety of personalities and knowledge bases. I expect to spend more time with a starting Business Analyst, reviewing his or her work, guiding, and mentoring.

I expect my mid-range Business Analyst to have strong analysis skills. This person needs to be able to review a lot of information, determine the actual requirements and their priorities, write the requirements in the most appropriate form for the project, and manage the requirements throughout the project lifecycle.  The mid-range Business Analyst will take on more leadership activities, and will be more self-directed. I expect to spend less time with the mid-range Business Analyst.

I think that a senior Business Analyst will be more of a specialist. This person might decide to become more of a project manager, or might focus on human/computer interaction, or develop more technical skills to work more closely with the development team. The senior Business Analyst will be completely self-directed.

Employers tend to focus heavily on subject matter expertise, which in practice I have found to be the least important part of my job. There are plenty of Subject Matter Experts (SME) at any company, and I work closely with them. As a Business Analyst, I am really a communication expert, and I have been extremely effective in that role in many companies. But it can be hard to sell yourself to an employer that way, especially at the beginning, so developing subject matter expertise in order to get your foot in the door is a good plan.

Keep in mind that the point of a Business Analyst job is not the subject matter expertise. Rather, work to develop good Business Analyst skills of elicitation, analysis, communication, and management of information and people. This will allow you to more easily transition jobs in the future, because your work is not dependent on a particular industry.

 

Think about the Business Analyst job. What do the best Business Analysts do? What is a good transition path from starting through senior level positions?

 

Who Runs a Software Project?

Author: Geri Schneider Winters

I work on a lot of really large software projects.  Over the years, it has become clear to me that three roles, and the interactions between people in those roles, are really vital for the success of a software project. These three roles are the Project Manager, Business Analyst, and Project Architect. This article discusses these three roles and their interactions.

The Project Manager is responsible for interactions with the Project Sponsor, and for managing the people, budget, and schedules of the project. The Business Analyst is responsible for determining the goals and business requirements of the project, communicating that information to the project team and project stakeholders, and verifying that the goals and business requirements are met. The Project Architect is responsible for determining the technical requirements of the project, interacting with Enterprise Groups to determine Enterprise level technical requirements for the project, and for guiding the technical team in the implementation. Decisions made by one of these people will impact the work of the others, so all three people work closely together throughout the project to accomplish the goals of the project.

In a very small project, the three roles may be filled by one person. In very large projects, each role may be a lead over a team of people who fill the role.  There could be a Project Manager managing a group of  assistant Project Managers, a Lead Business Analyst managing a team of Business Analysts, and a Project Architect managing a team of Software Architects and Designers.  This is not theory – I have often worked on projects large enough to require teams of people to fill these roles.

In this approach of sharing the project leadership between three roles, the Project Manager is ultimately responsible for the success of the project. The Business Analyst and the Project Architect report to the Project Manager, but being senior members of the team, they will often interact with the Project Manager as peers, each bringing a particular viewpoint and set of concerns to their meetings about the project.

The Project Manager, Business Analyst, and Project Architect meet regularly (at least weekly) to talk about the project and any issues that need to be addressed. Some issues will be resolved by one role, while others may require the collaboration of all three roles to resolve. It is important to the project that the three people in these roles respect each other’s expertise and talents. A smooth working relationship between the three roles leads to a smoothly running project.

Some projects may require additional leadership roles, such as a Deployment Manager or Test Manager.  So the leadership team may be larger for those projects.  I focus on the roles of Project Manager, Business Analyst, and Project Architect because every project I have seen needs leadership in those areas. The larger the project, the more work there is to do, and the more need there is to divide these roles among multiple people all of whom have leadership responsibilities.

 

Think about projects you have worked on.  How did the relationships between the Project Manager, Business Analyst, and Project Architect affect your project?  What other leadership roles have you seen on a project team?

 

Information – Kind of vs Form of

Author: Geri Schneider Winters

When working on a project, you want to consider what kind of information you have, and what form is the best for documenting that information. These are two different things. A use case is a form of documentation that can be used for a variety of purposes. Sometimes a use case represents requirements, and sometimes it does not. So do not confuse the kind of information with the structure or form of the information.

Sometimes the easiest thing to do at first is to think of everything as information. As you collect and categorize information, you can decide which things represent requirements of the solution, and which things are other kinds of information. Often when I start a project, I am not sure what I have at first. I’ll collect a lot of information, then I will start to see patterns and categories to that information. As I structure the information into these patterns and categories, the process helps me to determine which things are requirements and which are other kinds of information. After that, I decide what form of documentation to use to communicate that information. I start with the information first, then I decide how to structure that information, what forms to put it in.

A number of companies I have worked for were very focused on use cases. Everything was a use case, the only requirements they had were use cases. But this was causing problems, because all the requirements were not use cases, and they were using use cases for purposes other than requirements. Needless to say, people at these companies were very confused. So instead of focusing on how the requirements were structured (use cases), I focused everyone on the kind of information they were collecting. This information represents context or scope, but that information looks like future state. Once I had determined what kind of information they had, then I guided them to appropriate forms of documentation. I did have use cases for both context and requirements, and I had other kinds of requirements documents as well. This approach cleared up a lot of confusion at those companies.

I have used state machines for analysis and for detailed design. I have used use cases and activity diagrams for context as well as for requirements. A component diagram can represent a logical or a physical model. If you know what kind of information you have, you can make a separate decision about the form you use to communicate that information. Typically the form you use will depend on the audience (or consumers) of the information.

Here are some ideas of what I think of as kinds of information vs forms of information. You may not completely agree with the two lists, but I hope they lead you to thinking about the kinds of information as being separate from the forms of information.

Kinds of information

  • Context
  • Scope
  • Problems
  • Solutions
  • Requirements
  • Future State
  • Needs
  • Wants
  • Dreams
  • Wishes
  • Constraints
  • Limitations
  • Risks
  • Technology
  • Bug Reports
  • Feature Requests

Forms of information

  • Use Cases
  • Shall Statements
  • Test Cases
  • User Stories
  • Scenarios
  • User Interface Designs
  • Wireframes
  • FURPS
  • Prototypes
  • Flow charts
  • Activity diagrams
  • State machines
  • Truth tables
  • Report Specifications
  • Data Dictionaries
  • Data Models
  • Domain Models
  • Object Models
  • Business Requirements
  • Business Rules

 

Do you see that kind of information and form you put it in are two different things? What kinds of information do you work with? What forms of information do you work with?

 

What is Analysis?

Author: Geri Schneider Winters

As Business Analysts, our job goes far beyond being a note-taker, in other words listening to people talk, writing down what they say and calling it requirements. Notice that the term Business Analyst implies that we analyze. We need to analyze requirements and information and that is some of the skill we bring to the table. Andrew Midkiff and I were having lunch the other day and discussing what analysis means to us as working Business Analysts. And we came up with at least a couple of different things that a Business Analyst should do that are called analysis.

Andrew thinks of analysis as Requirements Analysis. So I asked him what he meant by that. A lot of people use that term, but what do they mean? He said Requirements Analysis is looking at the information that you are provided and analyzing it. It is a process where you probe and question to tease out the actual business needs that require a solution. You should be asking these kinds of questions:

  • Where is there a lack of information?
  • Where do you have not enough detail?
  • Do the requirements as they are given to you make sense, i.e. are these truly things that are required of the solution?
  • Does the information you were provided describe actual “requirements” in a business sense or something else, such as solution?
  • As you compare all the requirements and use cases you have collected to each other do they make sense as a whole? Is this a cohesive, accurate description of the project?
  • Has the stakeholder given you true requirements of the system, or rather a description of how things work today?

In this kind of analysis we really want to probe and question. I remember one company I worked for, an insurance company, there was a project to create a system to use to input applications for insurance. They were going to store information about the subscriber using a unique identifier, which was a good idea. So there was a requirement – “The system has to uniquely identify the subscriber”. But then they were going to store dependents of the subscriber by first name, because they assumed that would be unique. I probed and questioned, I asked them does this make sense. I gave some examples. Look at the example of George Foreman who named all of his children George Foreman. In a more common example, my sister was married and had a daughter she named Heather. She was divorced, and remarried a man who had a daughter named Heather. So now there were two Heathers in the same family. In both of these cases we have direct dependents of the subscriber who have the same name. This shows that the requirement to identify dependents by first name was a poor one. The requirement was rewritten as – “The dependents of a subscriber have to be uniquely identified within that policy.” As an Analyst it is my job to question that kind of thing, to really think about what I am being told. To question it and probe and make sure it really does make sense.

In a different perspective from Andrew’s, when I think of analysis I tend to think of information analysis. This is where I like to use something like a class diagram to show pieces of information and the relationships between the pieces of information. And I like to use a state diagram to show a particular piece of information and its states. What I am looking for is how the information changes over time and what causes those changes to happen. I’m not so interested in finding all the attributes of the class (or piece of information), but rather I want to know what about that information causes changes in my business process (or what in my business process causes changes in the information).

When I do that information analysis, I’m really looking at a perspective that cuts across the use cases. The use cases each describe individual processes. Then the information analysis goes across those processes to show how each of those processes contributes to some change in the information. This is also how I’m finding more business rules or triggers about what happens in the business over time as information progresses through the company.

 

Post a comment and let me know – when you think of analysis, what do you mean by it?

Are your thoughts more like mine, Andrew’s, or something different?

 

Using Personas

Author: Geri Schneider Winters

Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans).

You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike.

In looking over my survey, I find that 75% of you who responded are working Business Analysts. You are looking for a wide variety of information, but typically in shorter forms such as tips and examples, rather than classes. You are typically alone in front of your computer when looking for information, and could be anywhere at any time of the day or night. You are looking for an online, interactive, multimedia experience. So let’s take that information and develop some Personas.

I started off by imaging a relatively young person with some work experience who is really comfortable with the computer and internet, and who readily goes online to find information at any time a question arises. Now I imagine some real people and write their stories.


© Christophe Baudot . Image from BigStockPhoto.com

Karen Carmichael is 27 years old. She graduated from a U.S. college with a B.A. in Sociology and a minor in Information Systems. She has worked as a Business Analyst for a large bank in Chicago, Illinois for the 5 years since graduation on a wide variety of software projects. Karen is single and loves sports. She is a member of her company’s softball team in the summer, and an avid football and basketball fan in the fall and winter.

Karen feels that she received a fine education in college, but working on real projects for a major corporation is quite different from her school projects. She has many peers at her bank that she can talk with, but often situations arise that are not easy to resolve.

Karen is quite comfortable with a computer and searching for information on the internet. She really likes to be able to open up a search engine and find the answer to any question right away. The problem with search engines is that she often gets a lot of unrelated information in response to her queries. Karen has a number of sites bookmarked on her computer for her favorite sports teams. She wants to create a similar set of bookmarks for sites that have information for Business Analysts. When she has a question, she can just open a web browser and select a couple of those sites to find the information she needs.

© Mateusz Zagorski. Image from BigStockPhoto.com

Raj Reddy is 32 years old. He graduated from a prestigious Engineering College in India with a B.S. in Computer Science, and worked as a programmer in India for 3 years. He then came to the US and completed an MBA with the goal of managing software projects. He has been working as a Project Manager for a major health insurance organization in San Francisco, California for the last 5 years, taking on roles of increasing responsibility. Raj is married and his wife is in India. He wants to return to India to join his wife and family, and to bring what he has learned about software development to some of the smaller companies in his home state.

Raj plans to be a consultant and carry a computer with a wireless card everywhere he works. He wants to be able to quickly find information on the internet to help him in his job. This will include information about Business Analysis, because he often finds that the roles of Project Manager and Business Analyst overlap, so he needs to know how to do both jobs.

When he is not as busy with work, Raj likes to continually learn new things. It is hard for him to sign up for classes, because he may not be available for every class meeting. So having the classes online in a self-study format is a great solution. He wants to be able to study the material whenever he has time, and does not want to have a deadline for when he has to complete the class. Raj is a friendly guy, and fears he will miss the daily interactions with people at work. He is looking for an online community that he can access any time he is online to chat with other Business Analysts.

 

Post a comment and let me know – does either profile seem like you? Which one and why?

Try writing one or more personas about your customers so that the people and their needs are more real to you.

 

Use Cases Are Not the Only Requirements

Author: Geri Schneider Winters

With all the focus on Use Cases, it can be easy to forget that they are not the only kind of requirements. Use Cases are very good for some kinds of requirements, but really bad for other kinds of requirements. One of our challenges as Business Analysts is to determine the right way to document the requirements for a particular project.

When starting on a new project, one of the first things I want to find out is “Who or what is driving the requirements for this project?”. I was really reminded of this when I read Richard Denney’s book “Succeeding With Use Cases: Working Smart to Deliver Quality”, a book I highly recommend.

If the project is being driven by changes in processes, then Use Cases probably make a lot of sense, since they are good at describing processes. But you could also use User Stories, Scenarios, Flow Charts, or Test Cases to describe processes. Which you choose will depend on corporate culture and the software development process that is used on your project.

In this case, find out what is driving the process change. If the process change is coming from the way that people work, then you can find requirements by talking to the people or watching them work. If the process change is coming from a technology change, then you may need to start working on the requirements by learning about the new technology. I worked on one project which was to design software to run on hardware that tested IC chips. The source of my requirements was the tests that had to be run on the IC chips. I documented those tests as Use Cases because that is what the customer wanted me to use for requirements.

If the project is purely a change in underlying technology, then a lot of your requirements will be the non-functional requirements (often called FURPS). You might have to write these requirements as formal “Shall” statements. Look over a template for a Supplementary Specification for ideas of the kinds of requirements you might need.

For example, if I am installing COTS (commercial off-the-shelf) software, then I do not need Use Cases for how the software works. I might need Use Cases for how we will use the software in our company, if that information is not obvious. But I really need to know other kinds of information, such as how many users will use it at a time, what response is required, how many transactions per second it will have to handle, how many records will it have to store and process, and what kind of security is required to use it. I will have to talk with the folks in Enterprise Architecture to find any restrictions on where or how it can be installed. There may be a need for a new server, so I have to find out the contraints such as what platforms are allowed, or how much money we can spend on it.

In embedded systems, you may find that truth tables or state machines do the best job of describing the requirements. In this case, there is probably no human interaction, and the processes are all closely related to the hardware and how it works. A truth table or state machine is a good way to describe the different states of the system and how it is allowed to change.

Here are some ideas for kinds of things I have seen used (successfully) as requirements for different kinds of projects. Consider these to see if they are appropriate for your projects:

  • Use Cases
  • Shall requirements
  • Test Cases
  • User Stories
  • Scenarios
  • User interface designs
  • FURPS requirements
  • Prototypes
  • Flow charts
  • Activity Diagrams
  • State Machines
  • Truth Tables

 

How do you decide what kinds of things to use for requirements on your projects?

What other kinds of things have you used for requirements for your projects?