1. Lecture 8 Systems Analysis: Concept and Principles
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 Requirements Stated objectives/goals during meeting with the customer. E.g. Specific system functions.
Expexted Requirements Implicit requirements, customer does not explicitly state them, their absence can cause significant dissatisfaction. E.g. Ease of human/machine interaction.
Exciting Requirements Beyond 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