1 Requirements Analysis and Specification Requirements analysis.

Slides:



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

Software Engineering 1. Software development – the grand view 2. Requirements engineering.
Analysis Concepts, Principles, and Modeling
7.1 A Bridge to Design & Construction
1 R&D SDM 1 Software Project Management Requirements Analysis 2010 Theo Schouten.
Chapter 5 Understanding Requirements
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Software Testing and Quality Assurance
Chapter 2 Data Models Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
1 R&D SDM 1 Software Project Management Requirements Analysis 2009 Theo Schouten.
Requirements Analysis Concepts & Principles
Analysis Concepts and Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Analysis Concepts and Principle.
Purpose of Requirements Analysis Process of discover, refinement, modeling, and specification o Bridge gap between system level SW allocation and design.
SE 555 – Software Requirements & Specifications Introduction
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 Requirements Analysis and Specification Requirements analysis.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
S R S S ystem R equirements S pecification Specifying the Specifications.
Problem Solving Methodology
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7 Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Chapter 4 Requirements Engineering
Understanding Requirements. Requirements Engineering
CS 4310: Software Engineering Lecture 3 Requirements and Design.
CSI315 Web Applications and Technology Overview of Systems Development (342)
Requirements Analysis
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
IS 466 ADVANCED TOPICS IN INFORMATION SYSTEMS LECTURER : NOUF ALMUJALLY 22 – 10 – 2011 College Of Computer Science and Information, Information Systems.
2 1 Chapter 2 Data Models Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
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.
BMAN Integrative Team Project Week 2 Professor Linda A Macaulay.
Requirement Engineering Tasks Inception Elicitation Problems of scope Problems of understanding Problems of Volatility Elaboration Scenarios Negotiation.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Chapter 11 Analysis Concepts and Principles
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
Lecture 7: Requirements Engineering
Lecture-3.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
1 Chapter 5 Lecture 5: Understanding Requirements Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Systems Development Life Cycle
By Germaine Cheung Hong Kong Computer Institute
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Software Engineering Lecture 11: System Analysis.
Software Requirements Specification (SRS)
System Requirements Specification
Requirement Engineering
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
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.
Design Evaluation Overview Introduction Model for Interface Design Evaluation Types of Evaluation –Conceptual Design –Usability –Learning Outcome.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7: Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e.
 System Requirement Specification and System Planning.
MANAGEMENT INFORMATION SYSTEM
Software Quality Control and Quality Assurance: Introduction
Requirements Engineering
Software Engineering Development of procedures and systematic applications that are used on electronic machines. Software engineering incorporates various.
SYSTEM ANALYSIS AND DESIGN
Requirements Elicitation and Elaboration
System Requirements Specification
CS 790M Project preparation (I)
Software Requirements Specification Document
CHAPTER 9 (part a) BASIC INFORMATION SYSTEMS CONCEPTS
Requirements Document
Chapter 5 Understanding Requirements.
Dr. Jiacun Wang Department of Software Engineering Monmouth University
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

1 Requirements Analysis and Specification Requirements analysis

2 Requirements Analysis and Specification Requirements / specification customer developer requirements specifications

3 Requirements Analysis and Specification: Requirements / Specification: ----What is needed? ----If there is a current implementation, what are the problems with it? ----How can we translate customer needs and wants into a usable specification for the design stage? Initially, requirements may be fuzzy and poorly stated--analysis stage sharpens and focuses the (customer) requirements Requirements analysis and specification

4 Example: let’s redesign windows ----What is needed? ----Current implementation: what are the problems with it? ----How can we translate customer needs and wants into a usable specification for the design stage? Initially, requirements may be fuzzy and poorly stated--analysis stage sharpens and focuses the (customer) requirements Example

5 An example requirements analysis process: FAST (Facilitated Application Specification Techniques, in R.A. Zahniser, Building Software in Groups, American Programmer 3 (7-8), July-August, 1990.): GOAL: identify problem, negotiate differences, specify preliminary set of solution requirements --engineers AND customers meet at a neutral site --there are rules for preparation and participation in this meeting --agenda covers all important points but also allows flexibility for free flow of ideas --meeting controlled by facilitator --definition mechanism chosen (e.g., flip charts, electronic bulletin board.,etc.) Example requirements analysis process

6 Some tools for requirements analysis & specification: Requirements: ----formal requirements document Specification: ----use cases (UML) ----”user stories” (XP) Tools for requirements analysis

7 Requirements document must be as clear as possible, consistent, complete Important parts of a requirements document (Berezin, 1999): 1. Application Overview: -- objectives -- (business process—how application fits) -- user roles and responsibilities -- interactions with other systems -- (replacement of legacy systems) -- (production rollout considerations) -- terminology Requirements document

8 Important parts of a requirements document (continued): 2. Functional requirements: -- functionality precise, detailed, for each user class address security, auditing, reporting, ability of users to modify application -- (scope (for a multiphase project) ) 3. Quality requirements --performance (space / time / power) -- usability -- concurrency --portability --security / reliability --etc. Requirements document--continued

9 Specification: must be as complete as possible, consistent, clear Specification

10 Principles of specification: 1. functionality should be separate from implementation 2. model of system behavior must include both data and functional responses to external stimuli 3. interaction with other components must be specified 4. environment of operation must be defined 5. "cognitive model" should describe the system as seen by the user community; do not create a design or implementation model 6. must be tolerant of incompleteness and allow for additions 7. must allow for change Principles of specification

11 Result of specification step: Software Requirements Specification must include: --complete information description --detailed functional description --representation of system behavior --performance requirements --design constraints --appropriate validation criteria (for example, acceptance tests) --……. Software requirements specification

12 example candidate formats for specification: IEEE Department of Defense at the end of this process, customer and developer must conduct a Specification Review Specification format

13 “Redesign windows” requirement  specification for new product? Specification—one example

14 This quarter: Requirements will be written following the outline in the paper by Berezin Specifications will be written as UML use cases, along with text descriptions System acceptance tests will be written along with specifications Quarter Project