Requirements AnalysisSlide 2Analysis ObjectivesSoftware Requirements Analysis PhasesManagement QuestionsFeasibility StudySystem SpecificationRequirementsTypes of Requirements - 1Types of Requirements - 2Requirement ValidationRequirements Definition DocumentSoftware Requirements ElicitationF.A.S.T. - 1F.A.S.T. - 2Q.F.D. - 1Q.F.D. - 2Q.F.D. - 3Use CasesUser Profile - ExampleUse Case Example - 1Use Case Example - 2PowerPoint PresentationSlide 24Slide 25Analysis PrinciplesInformation DomainModelingPartitioningRequirements ViewsSpecification Principles - 1Specification Principles - 2Specification RepresentationSpecification ReviewRequirements ReviewEvaluating Specification Techniques - 1Evaluating Specification Techniques - 2Prototyping and SpecificationEvolutionary Rapid PrototypingE.R.P. ProcessE.R.P. RisksE.R.P. AdviceE.R.P. AnalysisImplementation and TestingEach Spin CycleRe-implementation Symptoms1Requirements AnalysisCIS 375Bruce R. MaximUM-Dearborn2Requirements Analysis•Software engineering task bridging the gap between system requirements engineering and software design.•Provides software designer with a model of: –system information–function–behavior•Model can be translated to data, architectural, and component-level designs.•Expect to do a little bit of design during analysis and a little bit of analysis during design.3Analysis Objectives •Identify customer’s needs.•Evaluate system for feasibility.•Perform economic and technical analysis.•Allocate functions to system elements.•Establish schedule and constraints.•Create system definitions.4Software Requirements Analysis Phases•Problem recognition•Evaluation and synthesis–focus is on what not how•Modeling•Specification•Review5Management Questions•How much effort put towards analysis?•Who does the analysis?•Why is it so difficult?•Bottom line - who pays for it?6Feasibility Study•Economic feasibility–cost/benefit analysis•Technical feasibility–hardware/software/people, etc.•Legal feasibility•Alternatives–there is always more than one way to do it7System Specification•Introduction.•Functional data description.•Subsystem description.•System modeling and simulation results.•Products.•Appendices.8Requirements•Requirement–features of system or system function used to fulfill system purpose.•Focus on customer’s needs and problem, not on solutions:–Requirements definition document (written for customer).–Requirements specification document(written for programmer; technical staff).9Types of Requirements - 1•Functional requirements:–input/output–processing.–error handling.•Non-functional requirements:–Physical environment (equipment locations, multiple sites, etc.).–Interfaces (data medium etc.).–User & human factors (who are the users, their skill level etc.).10Types of Requirements - 2•Non-functional requirements (continued):–Performance (how well is system functioning).–Documentation.–Data (qualitative stuff).–Resources (finding, physical space).–Security (backup, firewall).–Quality assurance (max. down time, MTBF, etc.).11Requirement Validation•Correct?•Consistent?•Complete?–Externally - all desired properties are present.–Internally - no undefined references.•Each requirement describes something actually needed by the customer.•Requirements are verifiable (testable)?•Requirements are traceable.12Requirements Definition Document•General purpose of document.•System background and objectives.•Description of approach.•Detailed characteristics of proposed system (data & functionality).•Description of operating environment.13Software Requirements Elicitation•Customer meetings are the most commonly used technique.•Use context free questions to find out–customer's goals and benefits–identify stakeholders–gain understanding of problem–determine customer reactions to proposed solutions–assess meeting effectiveness•Interview cross section of users when many users are anticipated.14F.A.S.T. - 1•Facilitated application specification technique•Meeting between customers and developers at a neutral site (no home advantage).•Goals–identify the problem–propose elements of solution–negotiate different approaches–specify preliminary set of requirements15F.A.S.T. - 2•Rules for participation and preparation established ahead of time.•Agenda suggested–brainstorming encouraged•Facilitator appointed.•Definition mechanism–sheets, flipcharts, wallboards, stickers, etc.16Q.F.D. - 1•Quality Function Deployment •Customer’s needs imply technical requirements:–Normal requirements(minimal functional & performance).–Expected requirements(important implicit requirements, i.e. ease of use).–Exciting requirements (may become normal requirements in the future, highly prized & valued).17Q.F.D. - 2•Function Deployment:–Determines value of required function.•Information Deployment:–Focuses on data objects and events produced or consumed by the system.•Task Deployment:–product behavior and implied operating environment.18Q.F.D. - 3•Value Analysis makes use of:–Customer interviews.–Observations.–Surveys.–Historical data.•to create–Customer Voice Table–extract expected requirements–derive exciting req.19Use Cases•Scenarios that describe how the product will be used in specific situations.•Written narratives that describe the role of an actor (user or device) as it interacts with the system.•Use-cases designed from the actor's point of view.•Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases.20User Profile - Example•Full Control (Administrator)•Read/Write/Modify All (Manager)•Read/Write/Modify Own (Inspector)•Read Only (General Public)21Use Case Example - 1•Read Only Users–The read-only users will only read the database and cannot insert, delete or modify any records.•Read/Write/Modify Own Users–This level of users will be able to insert new inspection details, facility information and generate letters. They will be also able to modify the entries they made in the past.22Use Case Example - 2•Read/Write/Modify All Users–This level of users will be able to do all the record maintenance tasks. They will be able to modify any records created by any users.•Full Control Users–This is