Alien Nation - Users and Developers

August 21st, 2008 chris

Users and developers are typically from different worlds, may even speak different languages, and have different backgrounds, motivations, and objectives. Communication gap between user and the developer accounts for the fact that understanding user needs remain one of our largest problems.

The problems are the following:

1. Users do not know what they want, or they know what they want but cannot articulate it.
2. Users think they know what they want until developers give them what they said they wanted.
3. Analysts think they understand user problems better than users do.
4. Everybody believes everybody else is politically motivated.

The solution:

1. Recognize and appreciate the user as domain expert; try alternative communication and elicitation techniques.
2. Provide alternative elicitation techniques earlier: storyboarding, role playing, throwaway prototypes, and so on.
3. Put the analyst in the user’s place. Try role playing for an hour or a day.
4. Politics is part of human nature, so let’s get on with the program.

Posted in Requirements

The Real Goal of Software Development

August 21st, 2008 chris

Thousands of software development teams worldwide are engaged right now in developing widely different software applications in widely different industries. But although we work in different industries and speak and write in different languages, we all work with the same technologies, we read the same magazines, we went to the same schools, and fortunately, we have the same clear goal:

“To develop quality software on time and on budget that meets customers’ real needs”

Posted in Requirements

Team Skills for Effective Requirements Management

July 11th, 2008 chris

1. Analyzing the Problem, gain a proper understanding of the problem that a new software system is intended to solve.
2. Understanding User and Stakeholder Needs, elicit requirements from the system users and stakeholders and ability to understand the real needs that the system must address.
3. Defining the System, converts an understanding of the problem and the users’ needs to the initial definition of a system that will address those needs.
4. Managing Scope, managing the scope of the project and  to negotiate an acceptable deliverable before success can be achieved.
5. Refining the System Definition, organize the requirements information and elaborate on the system definition, or refine it to a level suitable to drive design and implementation, so that the entire extended team knows exactly what kind of system it is building.
6. Building the Right System, design assurance, testing, and change management, and  traceability used to help ensure a quality outcome.

Posted in Requirements

Three Software Application Categories

July 11th, 2008 chris

If there are three kinds of customers, then I also have a list of three categories in Software Applications. They are the following:

Information systems and other applications developed for use within a company (such as the payroll system being used to calculate the take-home pay for our next paycheck). This category is the basis for the information system/information technology industry, or IS/IT.

Software developed and sold as commercial products (such as the word processor). Companies developing this type of software are often referred to as independent software vendors, or ISVs.

Software that runs on computers embedded in other devices, machines, or complex systems (such as those contained in the airplane we are writing this in; the cell phones we just used to call our spouses; the automobile we’ll use to get to our eventual destination). We’ll call this type of software embedded-systems applications, or embedded applications.

Posted in Requirements

Three Customers

July 11th, 2008 chris

For some of us, the customer is an external entity, purchase order in hand, whom we must convince to disregard our competitor’s claims and to buy our shrink-wrapped software product because it’s easier to use, has more functionality, and, in the final analysis, is just better.

For others of us, the customer is a company that has hired us to develop its software, based on expectations that the software developed will be of the highest quality achievable given today’s state of the art and will transform the company into a more competitive, more profitable organization in the marketplace.

For others of us, the customer is sitting down the hall or downstairs or across the country, waiting anxiously for that new application to enter sales orders more efficiently or to use e-commerce for selling the company’s goods and services so that the company we both work for will ultimately be more profitable and our jobs more rewarding and just more fun.

Posted in Requirements