Presentation on theme: "Lecture 8 Systems Analysis: Concept and Principles"— Presentation transcript:
1 Lecture 8 Systems Analysis: Concept and Principles Software EngineeringLecture 8Systems Analysis: Concept and Principles
2 IntroductionRequirement 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 RecognitionEvaluation and synthesisModelingSpecificationReview
5 Problem RecognitionGoal 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 ModelingThe 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: rolesAids 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 SpecificationThe 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 implementationA process-oriented systems specification language is requiredA specification must encompass the system of which the software is componentA specification must encompass the environment in which the system operatesA specification must be a cognitive modelA specification must be operationalA specification must be tolerant of incompleteness and augmentableA 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 AnalystResponsibility of a system analyst is to analyze and define systems of optimum performance, i.e. an output that fully meets management objectivesThe 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) informationHandling large and complex problems, i.e. as complexity increases, effort increasesAccommodating 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 agendaDetermine the facilitator who controls the meetingDetermine mechanism of the meetingCreate 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-CasesAs 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 ActorTo 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 modelingDevelop prototypesRecord the origin of and the reason for every requirementUse multiple view of requirementsRank requirementsWork to eliminate ambiguity.
22 PartitioningProblems 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 PrototypingPrototype 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.
Your consent to our cookies if you continue to use this website.