Purpose of Requirements Analysis Process of discover, refinement, modeling, and specification o Bridge gap between system level SW allocation and design.

Slides:



Advertisements
Similar presentations
Lecture 8 Systems Analysis: Concept and Principles
Advertisements

May 2, May 2, 2015May 2, 2015May 2, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa, CA.
Analysis Concepts, Principles, and Modeling
Analysis Modeling.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Analysis Modeling Over view of today’s lesson T he analysis model is the first technical representation of a system. Analysis modeling uses a combination.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Requirements Analysis Concepts & Principles
Software Requirements
Analysis Concepts and Principles
Nov. 14, 2007 Systems Engineering ä System ä A set or arrangement of things so related as to form a unity or organic whole. ä A set of facts, principles,
Introduction to Software Engineering Dr. Basem Alkazemi
Analysis Concepts and Principle.
1 Requirements Analysis and Specification Requirements analysis.
Software Engineering CSE470: Systems Engineering 35 Computer System Engineering Computer System Engineering is a problem-solving activity. Itemize desired.
1 Objective of today’s lesson S oftware engineering occurs as a consequence of a process called system engineering. Instead of concentrating solely on.
1 Requirements Analysis and Specification Requirements analysis.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
1 Requirements Analysis CIS 375 Bruce R. Maxim UM-Dearborn.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
Requirements Analysis
These slides are designed to accompany Web Engineering: A Practitioner’s Approach (The McGraw-Hill Companies, Inc.) by Roger Pressman and David Lowe, copyright.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Software Requirements Engineering CSE 305 Lecture-2.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
Introduction To System Analysis and Design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
Chapter 11 Analysis Concepts and Principles
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Chapter 9 요구사항 모델링: 시나리오 기반 방법론 Requirements Modeling: Scenario-Based Methods 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim.
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
Lecture 7: Requirements Engineering
Developed by Reneta Barneva, SUNY Fredonia for CSIT 425 Requirements Modeling.
Software Engineering Saeed Akhtar The University of Lahore Lecture 6 Originally shared for: mashhoood.webs.com.
1 Chapter 11 Analysis Concepts and Principles. 2 Requirements Analysis.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Requirements Engineering Requirements Elicitation Overview of Requirements Analysis.
Software Engineering Lecture 11: System Analysis.
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
Requirement Engineering
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Software Engineering Lecture 10: System Engineering.
RAD( Rapid application development ) Model RAD is a linear sequential development process model that emphasis an extremely short development cycle. Rapid.
Chapter: Requirement Engineering. Requirements Engineering  Requirement: A function, constraint or other property that the system must provide to fill.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
 System Requirement Specification and System Planning.
Requirements Analysis
Chapter: Requirement Engineering
An Overview of Requirements Engineering Tools and Methodologies*
System Design and Modeling
Software Engineering (CSI 321)
For University Use Only
Software Engineering Practice: A Generic View
Presented by KARRI GOVINDA RAO ,
Presentation transcript:

Purpose of Requirements Analysis Process of discover, refinement, modeling, and specification o Bridge gap between system level SW allocation and design o Enable system engineer to specify software function and performance o Indicate SW interface with other system elements o Establish design constraints o Analyst must : - Refine SW allocation and - build models of the process, data, and behavioral domains o RA provides SW designer with representation of info and function can be translated into data, architectural, and proce- dural design. o Allow developer and customer to assess quality

Analysis Tasks o Problem Recognition o Evaluation and synthesis o Modeling o Specification, o Review

Role of Analyst o Evaluate flow and content of information o Define and elaborate all SW functions o Understand SW behavior in context of events affecting system o Establish system interface characteristics o Uncover design constraints o Remember, assessing the WHAT! - What data? - What functions must system perform? - What interfaces? - What constraints apply?

Problem Areas o Communication Skills (different levels) - High-level interaction - More detail extraction from customer - Tailor communication approach towards customer o Facilitated Application Specification Techniques (FAST) Joint team of customer with developers (marketing, an- alysts, programmers, HW engrs)

Analysis Principles o Information domain of problem must be represented and understood. o Develop models that illustrate system info, function, and behavior o Models and problem should be decomposed into hier- archical organization o Process progress from essential (high- level requirements) to implementation details

Information Domain o All SW applications can be called data processing. Software is built to process data o SW also processes events o data and control (events) both reside within the Info Domain o 3 views of data and control as processed by computer programs 1. Information_Flow:______how data and control change as they move through system 2. Information_content:______represents individual data and control items making larger items of information (components wrt to data and events) 3. Information_structure:______Internal organization of data – control items (e.g. table, tree)

Modeling and Specification o Modeling____ - Aid in understanding information, function, and be- havior of system. - Focal point for review (determine completeness, con- sistency, and accuracy of specification) - Foundation for design: ("mapping" from presenta- tion to implementation context. o Partitioning/Decomposition_________ - Decompose large/complex problem into easily un- derstandable parts - Establish interfaces between parts to achieve overall functionality. –- Strive for hierarchical representation: – (partition uppermost element according to the fol- – lowing) O Increase detail by moving vertically O Increase breadth or functionality by moving hor- izontally.

Essential and Implementation Views o Essential_View____ of SW requirements: - Presents functions to be accomplished - Information to be processed - Without regard to implementation details o Implementation_View________ of SW requirements: - Presents "real-world" implementation perspective of processing functions and information data struc- tures - May be physical representation (depending on the objective)

Prototyping o Prototype is mostly for customer assessment o Several_steps_of_prototyping:_______ 1. Evaluate SW request and determine if feasible. 2. Develop abbreviated representation of requirements 3. Develop abbreviated design specification from re- quirements 4. Prototype SW is created, tested, and refined paper prototype through pictorial representations 5. Present prototype to customer: obtain feedback, then refine o Prototyping_Methods_and_Tools________ ___ - Fourth-generation techniques (database and report languages) - Reusable SW components - Formal Specification and Prototyping environments O Executable spec languages O Translate specs into exec. code

Specification Formal spec languages lead to formal representation of requirements that may be verified or further analyzed Specification_Principles:_____ o Cognitive model (take user's perspective) o Operational (be able to verify) o Tolerant of incompleteness and modifiable (abstract, may need refinement) o Localized and loosely coupled

Representation Guidelines o Representation format and content should be relevant to problem o Information contained within specification should be nested o Limited number of and consistent use of diagrams and other notational forms o Revisable representation (CASE tools)

Software Requirements Specification o Function and performance allocated to SW from sys- tem engineering should be refined by: - establishing complete information description - detailed functional description - performance requirements and design constraints - validation criteria o Standard formats (example: IEEE no )

Specification Contents - Introduction states goals and objectives of SW describe context of computer-based system - Information Description gives detailed descrip- tion of problem – O Information flow and structure documented – O HW, SW, and human interfaces described for ex- – ternal system elements and internal SW functions - Functional Description description of each func- tion needed to solve the problem – O Processing narrative for each function – O Design constraints: state and justify – O Give performance characteristics – O One or more graphical diagrams represent overall – structure and interaction between SW functions – and other system elements

Specification Contents - Behavioral Description examines operation of SW as consequence of – O external events and – O internally generated control characteristics - Validation Criteria: (very important) – O "How do we know if SW is successful implemen- – tation?" – O "What classes of tests are necessary to validate – function, performance, and constraints?" - Bibliography contains references to all documents that relate to software – O SE documentation (e.g., Handbook) – O Technical references (e.g., Algorithm texts, Pro- – gramming Language texts, Manuals) – O Vendor Literature (e.g., Sun OpenWindows) – O Standards (IEEE requirements standards)