Software Requirements - Background

Software Requirements ”Background

Software tools are developed for different reasons. For example, some people write software for their enjoyment; others write software to fulfill course requirements; yet others develop software systems to solve a problem they face. This chapter examines software systems that are developed for real customers in order to fulfill a customer s need. Relevant questions that should be asked at this stage are: How do customers define their needs? How can software developers help customers define the requirements?

In Chapter 2, we discussed how different software development methods deal with customer requirements. For example, the Unified Process describes use cases, which are what the user wants a computer system to do. The use cases usually represent the highest risks, and the requirements can be derived from them. Another approach to requirements definition is presented by eXtreme Programming (XP). XP advocates that in order to produce the software the customer needs, the customer should be on-site to give the developers ongoing feedback. In addition, XP outlines a very specific process (the Planning Game) for defining customer requirements (called customer stories ).

As hinted before, the specific development method one uses is of less importance as long as it ensures that customers get what they need. From this perspective, in the continuation of this chapter we look at how software requirements may be gathered.

Tasks  

1. Usually, students are given a list of requirements and are asked to develop a software system that meets these requirements. This task may help you experience some of the problems involved in defining software requirements. For this purpose, you are asked to assume that you are a customer who needs a software system for Web-based surveys.

   First, determine the type of business you have. Based on this decision, define your requirements for the Web-based system. Write these requirements as a person who is not a software developer.

   After you finish listing the requirements, analyze them:

   • What kinds of requirements did you list (user oriented, technology oriented, performance oriented, others)?

   • Compare the list you defined with real Web-based survey tools. Can you use existing tools as a resource for gathering requirements?

     This exercise is important for at least two reasons. First, you may be a customer of software systems and you will have to define the requirements of the software systems you need. Second, as a software developer, when you have real customers, such an experience may help you see the situation from the customer s point of view.

2. Based on your experience in Task 1, explain why requirements change is so predominant in software engineering.

3. As previously mentioned, data indicates that the percentage of software tools that meet customers needs is relatively low. Based on your experience in working on Task 1, explain this phenomenon .

4. Are there situations in which the software developers should participate in the gathering of information about the customer in order to help customers define their needs? If yes, what characterizes these situations? Why in these cases can t the software developers rely only on how customers define their requirements?

Discussion

This discussion is based on the requirements lists created in Task 1. During this discussion, each list can be checked, for example, according to its completeness and consistency. After several lists are reviewed, we recommend checking whether one system ”that is, one characterized by combining several requirements lists ”can be developed. In this way, we may get one product and the company may become a product-based company (in contrast to a company that has several versions of the same product, each version tailored for a specific customer).

If, during that discussion, requirements are changed, updated, altered , and so forth, discuss the reasons that lead to these changes. This is, in fact, how the process of defining requirements happens in everyday life and it is an excellent opportunity to reflect on that process (see Chapter 10, Learning Processes in Software Engineering ).