The Software Development Life Cycle: An Overview

Slides:



Advertisements
Similar presentations
Lecture 5: Requirements Engineering
Advertisements

Project management Project manager must;
Karolina Muszyńska Based on
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Ch 12: Object-Oriented Analysis
Requirements and Design
Software Testing and Quality Assurance
Soft. Eng. I, Spring 07Dr Driss Kettani, from I. Sommerville1 CSC-3324: Chapter 5 Requirements Engineering Reading: Chap. 6, 7 + annex.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
Capturing the requirements
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
CS351 © 2003 Ray S. Babcock Requirements What not How “The Pizza Experiment” 1994, 350 companies, 8000 software projects. 31% were canceled before they.
Software Requirements
Requirements (recap)‏
Soft. Eng. II, Spr. 2002Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 1 (cont ’d) Title : Client requirements (Review) Mandatory reading: I.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Overview of Software Requirements
© Copyright Eliyahu Brutman Programming Techniques Course.
1 CSC-3324: Chapter 4 Title: What is a requirement? Mandatory reading: Sommerville 6, 7 th ed., Chap.: 7.
1 Software Requirements Specification Lecture 14.
Karolina Muszyńska Based on
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
S R S S ystem R equirements S pecification Specifying the Specifications.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
CIS 321—IS Analysis & Design
RUP Requirements RUP Artifacts and Deliverables
Typical Software Documents with an emphasis on writing proposals.
Requirements Analysis
The Software Development Life Cycle: An Overview Presented by Maxwell Drew and Dan Kaiser Southwest State University Computer Science Program.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Lecture 7: Requirements Engineering
Requirements Collection By Dr. Gabriel. Requirements A requirement is any function, constraint, or property that the system must provide, meet, or satisfy.
Requirements Engineering Overview Senior Design Don Evans.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
Capturing the requirements  Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the.
L To identify the services that the customer requires from a system and the constraints under which it operates and is developed.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Systems Development Life Cycle
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Week 3: Requirement Analysis & specification
The Software Development Life Cycle: An Overview
Software Requirements Specification Document (SRS)
Requirements Analysis
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
Requirement Elicitation Review – Class 8 Functional Requirements Nonfunctional Requirements Software Requirements document Requirements Validation and.
 The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.  However,
1 Software Requirements Descriptions and specifications of a system.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
 System Requirement Specification and System Planning.
Requirements Analysis
Requirement Engineer Terms and Conditions
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
INTRODUCTION OF REQUIREMENT ENGINEERING Chapter- one.
Presentation transcript:

The Software Development Life Cycle: An Overview Presented by Maxwell Drew and Dan Kaiser Southwest State University Computer Science Program

Last Time Project Management Concepts The Schwan’s Information Services Deliverables Guide Project Management Techniques Project Management in MSF Project Management in RUP

Session 3: Agenda The Requirements Process Schwan’s Requirements Phase MSF Requirements RUP Requirements

Requirements Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose Three kinds of requirements: those that absolutely must be met those that are highly desirable but not necessary those that are possible but could be eliminated

Purpose of Requirements To establish and maintain agreement with the customers and other stakeholders on what the system should do. To provide system developers with a better understanding of the system requirements. To define the boundaries of (delimit) the system. To provide a basis for planning the technical contents of iterations. To provide a basis for estimating cost and time to develop the system. To define a user-interface for the system, focusing on the needs and goals of the users.

The Requirements Document The requirements document is the official statement of what is required of the system developers Should include both a definition and a specification of requirements It is NOT a design document. As far as possible, it should set out WHAT the system should do rather than HOW it should do it

Requirements Requirements definition Requirements specification A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers Requirements specification A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

Functional vs. non-functional requirements Functional: describes an interaction between the system and its environment Examples: System shall communicate with external system X. What conditions must be met for a message to be sent Non-functional: describes a restriction or constraint that limits our choices for constructing a solution Examples: Paychecks distributed no more than 4 hours after initial data are read. System limits access to senior managers.

Types of requirements Physical environment Interfaces Users and human factors Functionality Documentation Data Resources Security Quality assurance

Requirements Readers

Different Perspectives

Characteristics of requirements Are they correct? Are they consistent? Are they complete? Are they realistic? Does each describe something the customer needs? Are they verifiable? Are they traceable?

Requirements Engineering Process Feasibility study Find out if the current user needs can be satisfied given the available technology and budget? Requirements analysis Find out what stakeholders require from the system Requirements definition Define the requirements in a form understandable to the customer Requirements specification Define the requirements in a detailed form for the designer

RE Process and its Deliverables

Discovering Requirements Prototyping Throw Away Evolutionary Both referred to as “rapid” prototyping Use Cases Will be discussed later

Expressing Requirements Formal Methods Axiomatic Definition Specification Grammars Mathematical Specifications Recurrence Relations Petri Nets Formal methods have not been generally accepted by developers

Data Abstraction

Abstract Class Relationships

Transition Diagram (UML)

Entity Relationship Modeling

Example ERD

Object-Oriented Specifications Each entity in the system is an object. A method or operation is an action that can be performed directly by the object or can happen to the object. Encapsulation: the methods form a protective boundary around an object. Class hierarchies of objects encourage inheritance. Polymorphism: same method for different objects, each with different behavior

Multiple Inheritance

Choosing a Specification Technique Applicability Implementability Testability/simulation Checkability Maintainability Modularity Level of abstraction /expressibility Soundness Verifiability Run-time safety Tools maturity Looseness Learning curve Technique maturity Data modeling Discipline

Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error Prototyping is an important technique of requirements validation

Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology

Validation Techniques

Questions?

Schwan’s Requirements Deliverables

Project Requirements Objective The objective of the Project Requirements phase is to identify and document the business requirements for the project.  Business requirements define the vision for the completed project in terms that the customer and user can understand and should concentrate on the business processes rather than technical processes.

Business Specifications (210) Objective The objective of the Business Specifications is to define the business rules and give a high level overview of the way the business processes are completed. The DBA’s may be involved at this stage. Required:Projects Optional:Support Deliverable to:Systems Development Customer (Optional) Deliverables Business Event Model Retention: System Business Event Document Retention: System Functional Decomposition Diagram Retention: System Context Diagram Retention: System

Entity/Relationship Modeling (220) Objective The objective of the Entity/Relationship Diagram is to define an Entity/ Relationship model and approve a Logical Data model with logical attributes (where database changes are needed). Cardinalities will be included to show the business flow and how the system potentially will work. DBA’s should be involved in this step. Required:Projects Optional:Support Deliverable: Entity/Relationship Diagram Logical Data Model Deliverable to: Systems Development Customer (Optional) Responsibility:Business Systems Planning

Input/Output Requirements (230) Objective The objective of the Input/Output Requirements is to develop the initial input and output requirements with the customer’s input and then review with the customer. Required: Projects Optional: Support Deliverable: Input Requirements Output Requirements Deliverable to: Systems Development Customer Responsibility: Business Systems Planning SAP Tie: 2.4

Prototyping (240) Objective The objective of the prototyping is to have the customer see the system and be able to give suggestions and approve the potential layout of the system. This is the beginning of reviewing potential third party packages if this is an option. Required: <None> Optional: Projects, Support Deliverable: Customer Approval (Walkthrough form?) Deliverable to: Systems Development Customer Responsibility: Joint Responsibility SAP Tie: 2.3,2.5

Detailed Business Specifications (250) Objective The objective of the Detailed Business Specifications is to detail the high level Business specifications’ using a method such as business use cases. Required: Projects Optional: Support Deliverable: Technology Model Business Use Cases Business Detail Process Documentation Deliverable to: Systems Development Customer (Optional) Responsibility: Business Systems Planning SAP Tie: 2.4

Business Test Cases (260) Objective The objective of the Business Test Cases is to have a written plan to confirm after creation that the system meets the business needs of the customer. This plan should include a list of functionality needed at the business level. Customers should help create the Business Test Cases. Required: ProjectsSupport Optional: <None> Deliverable: Business Test Cases Deliverable to: Systems Development Customer (Optional) Responsibility: Business Systems Planning SAP Tie: 2.4

Project Approval Objective The objective of the Project Approval phase is to make sure that everyone involved agrees on the requirements and that costs and estimates are reasonable.

Project Approval Steps IS Review Requirements Walkthrough Customer Review Development Review Project Estimation

Statement of Work Objective The objective of the Statement of Work is to estimate: Project Design Phase Only <or> Project Design and Project Development Phase. The scope of this Statement of Work will be dependent on how large the project is and if Design would be better suited to it’s own Statement of Work. A project Plan should be created and approved with Systems Development before the SOW is signed.

Questions?