Even with careful identification of sources of information and careful character-ization of requirements information, there will still be many problems. It is dif-ficult to provide a clean set of requirements. Software engineers must make sure that they are addressing the problem and not adding useless enhancements to it.
Software Engineers must continuously think whether the solution to the problem is important and necessary, or else it’s an enhancement. Common problems with requirement information are (Berard1993):
• Omissions: We refer to the process of focusing on the essential (or important) details of an item or situation while ignoring the inessential. Very often, the initial set of user-supplied information is incomplete. This means that, during the course of analysis, the software engineer will be expected to locate and/or generate new requirements information. This new information is, of course, subject to the approval of the client.
• Contradictions: Contradictions may be the result of incomplete information, imprecise specification methods, a misunderstanding or a lack of a consistency check on the requirements. If the user alone cannot resolve the contradictions, the software engineer will be required to propose a resolution to each problem.
• Ambiguities: Ambiguities are often due to lack of precision in the specification method and incompletely defined ideas.
• Duplications: Replication of information in the same format. Software engineer must be careful in removing these.
• Inaccuracies: Most commonly inaccuracies are due assumptions. These inac-curacies must be brought to the client’s attention and resolved.
• Too much design: One of the greatest problems in requirement analysis is finding the solution to the defined problem in the same stage. A meta-requirement is a design decision that is presented in the form of a system (product) requirement.
Meta-requirements describe situations and items that are not externally-discernible characteristics of the system to be delivered. True meta-requirements are not suggestions. They are items that the customer absolutely requires in the solution.
• Failure to identify properties: Sometimes, software engineers make the mis-take of assuming that any solution to the customer’s problem can only contain items that were explicitly mentioned in the problem description and/or the problem-space module. Some of the requirements properties could be implicit and hidden in other requirements.
• Irrelevant information: One straightforward way to describe a solution to a problem is to focus on what is essential, while ignoring what is inessential.
6.8 Chapter Summary and Conclusions
A requirement is a quality that a software system must have. This could be an activity that it must perform, an interface that it must contain or an environment within which it must operate. Requirements are criteria that a system must meet if it to work as intended, and thus must be considered mission critical if a software engineering project is to be successfully completed. In the last chapter, we dis-cussed the process of eliciting these requirements from the client and from the end user. Those requirements first elicited, however, are often times far from perfect.
In this chapter we discussed the analysis phase of the software life cycle. This phase is focused on refining, improving and finalizing the requirements specifi-cation, a formalized understanding of the system that will be the primary resource for the rest of the development process. At the beginning of the analysis phase, requirements usually suffer from one or more of the following problems:
• omitted information
• contradictory information
• ambiguous information
• inaccurate information
• irrelevant information
The analysis phase seeks to correct these problems through the systematic evaluation, modification and refinement of a system’s requirements. The system requirements gathered during the requirements elicitation phase are then complied into a final, functional requirements specification. During analysis, systems ana-lysts review requirements with a goal of identifying and correcting, missing or erroneous information. Interviews used in the requirements elicitation phase are reviewed. When the analysts discover errors or omissions during this evaluation period, new information is gathered to fill in the gaps by carrying out new,
122 6 Object-Oriented Analysis
improved interviews. At the end of the analysis phase, a final requirements specification or requirements specification statement is formed into the specifi-cation document, a document that formally expresses all of the requirements that make up the system.
6.9 Exercises
1. Does Object-oriented Analysis preclude any kind of software implementation?
2. Describe how, in the face of changing problems, practices and people, analysis has evolved, or should have evolved. Include a consideration of the appro-priateness of the terms that have been used for the job.
3. Consider a file system with GUI. The following objects were identified from a use case describing how to copy a file from a floppy disk to a hard disk: FILE, ICON, Trashcan, Folder, Disk, Pointer. Start the analysis process on this.
4. Assuming the same file system before, consider a scenario consisting of selecting a File on a floppy, dragging it to Folder and releasing the mouse.
Identify attributes and look for irrelevant objects.
5. Depict the above scenario through UML diagrams (any model described in the chapter can be used).
6. Consider a traffic light system at a four-way crossroads. Assume the simplest algorithm for cycling through the lights. Identify objects, states, attributes and draw a statechart diagram describing them.
7. You are asked to design a group scheduler. The software allows you to arrange meetings among individuals or groups and to reserve a limited number of conference rooms. Implement the object-oriented analysis phase on this.
8. Perform OOA on the following requirements for a checkers game:
• Checkers is played by two people, one with light and one with dark pieces.
• Pieces move diagonally and opponents are captured by jumping over them.
• A Piece can only move and capture forward.
• When a piece makes it to the other side of the board, it becomes a king and can move diagonally in any direction as far as it wants.
• Capturing is mandatory. A piece (or king) that is captured is removed from the board.
• The player who has no pieces left or cannot move anymore has lost the game.
9. Complete the OOA phase for a Tic-Tac-Toe Computer Game using the fol-lowing description. Tic-Tac-Toe is a 2 player game played on a 3 9 3 board.
Players alternate placing a marker in one of the squares on the board. If a player gets 3 of their markers in a row, they win. If all squares are full, and neither player has 3 in a row, the game is a draw. Statistics should be kept for each player on total games won, lost and drawn. Traditional Markers are X and O.
10. Design using UML any of the OOA models for worm game application. In this game, a worm, controlled by the user, navigates the 2 dimensional screen and eats pieces of ‘‘candy’’. When a piece is eaten, the worm grows by one segment. If the worm runs into the wall, or runs into itself, the worm dies and the game is over. As time increases, the speed of the worm increases. You should focus on the states of the application, but not the worm. Start from the initial state (application is not initialized) and final state (application is destroyed). Define the states between these two. Then connect states with events and transitions (events can come to the game from ‘‘outside’’ also).
Consider, for example, the following events:
• Start game
Are there any other events or transitions, such as time events, signals, or self-transitions?
References
Abbott RJ (1983) Program design by informal English descriptions. Commun ACM 26(11):882–894
Bentley LD, Dittman KC, Whitten JL (2004) Systems analysis and design methods
Berard EV (1993) Essays on object-oriented software engineering, vol. 1. Prentice-Hall, Inc..
Booch G (1994) Object-oriented analysis and design with applications. The Benjamin/Cummings Publishing Company, Inc., New York
Bruegge B, Dutoit A (2004) Object-oriented software engineering: using UML, patterns, and java, 2nd edn. Pearson Education, Ltd., Upper Saddle River
Carroll JM (1995) Scenario-based design: envisioning work and technology in system development
Coad P, Yourdon E (1990) Object-oriented analysis. PrenticeHall, Englewood Clis, New Jersey Holtzblatt K, Beyer HR (1995) Requirement gathering: the human factor. Commun ACM, vol 38 IEEE Computer Society (1998) Software Engineering Standards Committee, and IEEE-SA Standards Board. IEEE Recommended Practice for Software Requirements Specifications, Institute of Electrical and Electronics Engineers
Keil M, Carmel E (1995) Customer-developer links in software development. Commun ACM, vol 38 Miller R (2003) Practical UML: a hands-on introduction for developers. Available via
Embarcadero.http://edn.embaracardero.com/article/31863. Accessed 1 Dec 2003
Monarchi DE, Puhr GI (1992) A research typology for object-oriented analysis and design.
Commun ACM 35(9):35–47
Schach S (2008) Object-oriented software engineering. McGraw-Hill Higher Education, Boston Stiller E, LeBlanc C (2002) Project-based software engineering. Addison-Wesley, Boston
124 6 Object-Oriented Analysis
System Design
System design involves a process to fulfill user requirements. Constraints imposed on the project and on the user requirements may interact in complex ways to produce several designs rather than a single design. The result of the design phase is several system design deliverables as a design report which is ready for eval-uation. System design as described by Sommerville is concerned with how the system functionality is to be provided by different components of the system. The activities in the process are (Sommerville1996):
• Partition requirements: During this phase requirements are analyzed and formed into groups.
• Identify systems: This activity is concerned with identifying different sub-systems which meet the requirements.
• Assign requirements to subsystems: In this phase, the requirements are assigned to subsystems. In principle there is never a clean match between requirements partitions and identified sub-systems.
• Specify sub-system functionality: this may be seen as a system design phase or software system design phase.
• Define sub-system interfaces: This critical activity involves defining the inter-faces that are provided and expected by each sub-system (Fig.7.1).
The system analysis and design phase depend on each other. This Phase of the SDLC continues from the Detailed System Analysis and describes how the proposed system will be built. The design is specific to the technical environment that the system will operate in and the tools used in building the system. The results of this phase significantly impact the build and implementation phases of the system. The project manager is responsible for producing the deliverables associated with the detailed system design. A good system design process should therefore result in a system which can be implemented in either hardware or software. However, the project manager usually delegates responsibility for some or all of these deliverables to the development team. If some or all of the phase’s deliverables have been delegated, the project manager maintains overall responsibility for producing quality deliverables submitted.
R. Y. Lee, Software Engineering: A Hands-On Approach,
DOI: 10.2991/978-94-6239-006-5_7, Atlantis Press and the author 2013
125