the software development life cycle: an overview presented by maxwell drew and dan kaiser southwest...
TRANSCRIPT
The Software DevelopmentLife Cycle: An Overview
Presented by
Maxwell Drewand
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 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
1. The software must provide a means of representing and1. accessing external files created by other tools.1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
Requirements definitionRequirements specification
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 ReadersClient managersSystem end-usersClient engineersContractor managersSystem architectsSystem end-usersClient engineersSystem architectsSoftware developersClient engineers (perhaps)System architectsSoftware developersRequirementsdefinitionRequirementsspecificationSoftwarespecification
Different PerspectivesHow developers see users How users see developers
Users don’t know what they want. Developers don’t understand operational needs.Users can’t articulate what they want. Developers place too much emphasis on
technicalities.Users have too many needs that are politicallymotivated.
Developers try to tell us how to do our jobs.
Users want everything right now. Developers can’t translate clearly-stated needs intoa successful system.
Users can’t prioritize needs. Developers say no all the time.
Users refuse to take responsibility for the system. Developers are always over budget.Users are unable to provide a usable statement ofneeds.
Developers are always late.
Users are not committed to system developmentprojects.
Developers ask users for time and effort, even to thedetriment of the users’ important primary duties.
Users are unwilling to compromise. Developers set unrealistic standards forrequirements definition.
Users can’t remain on schedule. Developers are unable to respond quickly tolegitimately changing needs.
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 DeliverablesFeasibilitystudyRequirementsanalysisRequirementsdefinitionRequirementsspecificationFeasibilityreport SystemmodelsDefinition ofrequirementsSpecification ofrequirementsRequirementsdocument
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 AbstractionSemester record
Semester typeSemester dateGrade-point averageCompleted hours
Semester type(Fall, Spring, Summer)
Address informationTelephone numberStreet addressCityStatePostal code
Student recordNameStudent numberAddress informationNumber of semesters{Semester record}
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
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 TechniquesTable 4.6. Requirements validation techniques.
Manual techniques ReadingManual cross-referencingInterviewsReviewsChecklistsManual models to check functions and relationshipsScenariosMathematical proofs
Automated techniques Automated cross-referencingAutomated models to enact functionsPrototypes
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 DevelopmentCustomer (Optional)
Deliverables
Business Event ModelRetention: System
Business Event DocumentRetention: 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 DiagramLogical Data Model
Deliverable to:
Systems DevelopmentCustomer (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 RequirementsOutput Requirements
Deliverable to:
Systems DevelopmentCustomer
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 DevelopmentCustomer
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 ModelBusiness Use CasesBusiness Detail Process Documentation
Deliverable to:
Systems DevelopmentCustomer (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 DevelopmentCustomer (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.