Software Engineering

1. Software Engineering Lecture 8 Systems Analysis: Concept and Principles

2. Introduction • Requirement Analysis the process of discovering, refinement, modeling and specification in a software project. • Will always involve both the customer and system engineer, allowing the system engineer to achieve a set of objectives: • Specify software function and performance. • Indicate software interface with other system elements. • Establish design constraints that the software must meet.

3. Requirements Analysis • Requirement Analysis is also concerned with the preparation of the Software Requirements Specification: • A formal document that specifies in precise terms the functional and performance requirements of the software. • Specification document in turn will allow the developer and customer to assess quality once the software itself has been built. • The software developer performing Requirement analysis would often be known as the System Analyst.

4. Requirements Analysis Tasks • Problem Recognition • Evaluation and synthesis • Modeling • Specification • Review

5. Problem Recognition • Goal of analyst here is recognition of the basic problem elements as perceived by user and customer. • Understand software in the system context. • Define software scope. • Analyst will also need to establish contact with management and technical staff of the customer and software development organization.

6. Evaluation and Synthesis • The analyst must now evaluate the flow and content of information. • Define and elaborate all software functions. • Understand software behavior in the context of events that affect the system. • Establish system interface characteristics and uncover design constraints. • Throughout this step, the emphasis is on what must be done, not how it will be done. • This step will continue until both the analyst and customer feels confident that software can be adequately specified for subsequent development steps.

7. Modeling • The analyst creates models of the system in an effort to better understand data and control flow, functional processing, operational behaviour, and information content.

8. Modeling: roles • Aids in understanding the information, function and behavior of a system. • Makes requirement analysis task easier and more systematic. • It serves as a basis for creating specification for the software. • Becomes the focal point for review. • Becomes the foundation for design.

9. Specification • The specification is a representation of software that can be reviewed and approved by the customer. • Usually developed as a joint effort between the developer and the customer.

10. Specification Principles (Balzer and Goodman, 1986) • Separate functionality from implementation • A process-oriented systems specification language is required • A specification must encompass the system of which the software is component • A specification must encompass the environment in which the system operates • A specification must be a cognitive model • A specification must be operational • A specification must be tolerant of incompleteness and augmentable • A specification must be localized and loosely coupled

11. Review • Review of analysis documents like specification. • Review should first be conducted at a macroscopic level. • Conducted by customer and developer. • Results in modifications to: • Functions. • Performance. • Information representation. • Constraints. • Validation criteria.

12. The System Analyst • Responsibility of a system analyst is to analyze and define systems of optimum performance, i.e. an output that fully meets management objectives • The analyst must also exhibit the ability to: • Grasp abstract concept, partition them and generate solutions based on each division. • Understand implicit information, separate them and treat them individually. • Absorb pertinent facts from conflicting sources. • Understand the customer environment. • Apply hardware and/or software system elements to the customer environment. • Communicate well in written and verbal form.

13. Problems in Requirements Analysis • Requirement analysis is a communication-intensive activity where communication is concerned. • Miscommunication and omission often occur between the system analyst and customer. • Successful acquisition of information cannot be guaranteed. • Analyst have difficulties: • In getting pertinent (appropriate) information • Handling large and complex problems, i.e. as complexity increases, effort increases • Accommodating changes that occur during and after analysis

14. Communication Techniques • Conduct a preliminary meeting or interview. • Facilitated Application Specification Techniques (FAST) encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of solution, negotiate different approaches and specify a preliminary set of solution requirements.

15. FAST guidelines • Conduct meeting at a neutral side. • Establish rules • Prepare an agenda • Determine the facilitator who controls the meeting • Determine mechanism of the meeting • Create a conducive environment in order to meet the goals.

16. Quality Function Deployment • Quality Function Deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. • QFD concentrates on maximizing customer satisfaction from the software engineering process. • QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.

17. QFD three types of requirements • Normal RequirementsStated objectives/goals during meeting with the customer. E.g. Specific system functions. • Expexted RequirementsImplicit requirements, customer does not explicitly state them, their absence can cause significant dissatisfaction. E.g. Ease of human/machine interaction. • Exciting RequirementsBeyond customer’s expectation, very satisfying when present. E.g. Standard word processing software is equipped with page layout capabilities tha are quite pleasing and unexpected.

18. Use-Cases • As requirements are gathered as part of informal meetings, FAST, or QFD, the analyst can create a set of scenarios that identify a thread of usage for the system to be constructed. • The scenario is called use-case, which provides a description of how the system will be used.

19. Actor • To create a use-case, the analyst must first identify the different types of people (or devices) that use the system of product. • These actors actually represent roles that people (or devices) play as the system operates. • An actor is anything that communicates with the system or product and that is external to the system itself. • An actor and a user are not the same thing.

20. Use Case • Once actors have been identified, use cases can be developed. • The use case describes the manner in which an actor interacts with the system. • In general, a use-case is simply a written narrative that describes the role of an actor as interaction with the system occurs.

21. A set of guidelines for requirements engineering (Davis, 1995) • Understand the problem before modeling • Develop prototypes • Record the origin of and the reason for every requirement • Use multiple view of requirements • Rank requirements • Work to eliminate ambiguity.

22. Partitioning • Problems are often too large and complex to be understood as a whole. • Partitioning decomposes a problem into its constituent parts. • Use the ‘divide and conquer’ method.

23. Prototyping • Prototype is a model of the software to be built, which is constructed for customer and developer assessment. • The prototyping paradigm can be either close-ended or open-ended. • Close-ended, called throwaway prototyping, serves solely as a rough demonstration of requirements, then discarded. The software is engineered using a different paradigm. • Open-ended, called evolutionary prototyping, the prototype is the first evolution of the finished system.

24. References • Pressman, Chapter 10-11