CS480-Winter-2014-We..

Software
Engineering
Projects
Software Requirements
Software Requirements
Requirements Analysis
• Project Life Cycle
– Problem Definition
– Problem Analysis
• Analyze current processes
• Identify problem areas
• Recommend Solution
–
–
–
–
–
–
Project Proposal (RFP)
Project Charter (scope, objectives & participants)
Requirements Capture & Analysis
Design
Implementation
Verification
Software Requirements
Requirements Gathering
• Problems with Requirements Gathering
–
–
–
–
–
–
–
–
Not always obvious
Come from multiple sources
Often inconsistent and sometimes faulty
Effective requirement gathering requires domain
knowledge
Hard to express and model
Related to other artifacts
Quite often are unstable
Difficult to manage and track in large numbers
Business Requirements
Requirement Approaches
(Arthur de Snaijer, Requirement Practices, The shift towards Agile)
Business Requirements
Documentation Templates
• Software Engineering: Useful document
Templates & Checklists, www.iturls.com
http://www.iturls.com/English/SoftwareEngineering/SE_c.asp
• Artifacts for Agile Modeling: The UML and
Beyond, www.agilemodeling.com
http://www.agilemodeling.com/essays/modelingTechniques.htm
Business Requirements
Documentation Templates
• R.S. Pressman & Associates, Inc. Adaptable
Process Model, Document Templates,
www.rspa.com
http://www.rspa.com/docs/index.html
• Construx, Software Development Best Practices,
Agile Framework, Survival Guide,
www.construx.com
http://www.construx.com/Page.aspx?nid=95
Business Requirements
Class Project – Big Data App
Problem Definition
• Microsoft Dynamic GP is traditional ERP
solution consisting of Sales, Purchasing,
Inventory and Accounting modules
• There is no easy way to relate and search for
data across different modules
• The table structures are too long and require
complicated joins to collect necessary data
Action Items
Class Project – Big Data App
Solution Identification
• Extract Sales Data from Microsoft Dynamics
GP into BigData Storage System
• Develop Client Applications that query data
from the BigData Storage
– Client Apps connect to BigData Storage System via
Restful Web Service
Action Items
Software Modeling
Requirements
Capture
Requirements
Analysis
System Design
Software Modeling
Agile methods and requirements
• Many agile methods argue that producing a requirements
document is a waste of time as requirements change so
quickly.
• The document is therefore always out of date.
• Methods such as XP use incremental requirements
engineering and express requirements as ‘user stories’
(discussed in Chapter 3).
• This is practical for business systems but problematic for
systems that require a lot of pre-delivery analysis (e.g. critical
systems) or systems developed by several teams.
Chapter 4 Requirements engineering
11
Users of a requirements document
Chapter 4 Requirements engineering
12
Unified Modeling Language
• An attempt at standardizing article of analysis
and design:
– Models,
– Notation, and
– Diagrams
• Visio UML 2.2 Stencil
– http://www.softwarestencils.com/uml/index.html
Software Modeling
UML - Use Cases
• Use case diagrams are used to model and
communicate:
– Business Requirements
– Project Scope
– Stakeholders
– System Boundaries
Software Modeling
UML - Use Cases
communication
association name
use case name
actor name
•
Use Case Notation
– The stick-figure represents a role
taken on by an actor.
– Actors are never part of the system.
They only interact with the system
– A line connects the actor/role to the
use case in which it participates.
– Use case is any thing actor can
perform in relation to the system.
Software Modeling
UML Use Case - Example
UML - Activity Diagrams
• Used for Business Process Modeling
• Used to capture logic of:
– A complex operation
– A complex business rule
– A single use case
– Several use cases
– A business process
– Software processes
Software Modeling
UML - Activity Diagrams
Software Modeling
UML - Domain Object Model
• Domain Model depicts the physical (users, artifacts,
etc.) or abstract objects and their associations in the
business environment.
– The boxes represent the entities (types of objects).
– Links between the boxes show their relationships.
– Quite often they become the foundation of a data model
(Entity Relationship Diagrams)
– In complex systems Domain Object Model might be
skipped all together, and Data Modeling be used instead.
Software Modeling
UML - Domain Object Model
Software Modeling
Data Modeling - ER Diagrams (ERD)
• Data Modeling is a set of techniques for organizing
and documenting a system’s data
• It is also sometimes called Database Modeling as it is
usually implemented as a Database
• Entity Relationship Diagram (ERD)
– A data modeling technique that depicts the relationships
between different categories of data within a business
environment
– However it does not say anything about how data is,
• Implemented, Created, Modified, Used, or Deleted
Software Modeling
Data Modeling - ER Diagrams (ERD)
• Notation
Software Modeling
• Example
Data Modeling
ERD
Relationships
(Oracle Database Java Developer Guide, 2004)
Software Modeling
Structured Query Language (SQL)
•
•
•
Designed for retrieval and management of data in relational database
management systems
First version was created by IBM in 1970s
CRUD: Create, read, update and delete (CRUD) are the four basic functions of data
storage.
–
–
–
–
–
CREATE <Table, View, Index, Stored Proc, Trigger>
INSERT INTO <Table> (<Field1, Field2, …>)
VALUES (<Value1, Value2, …>)
SELECT <Columns>
FROM <Table>
WHERE <Condition>
UPDATE <Table>
SET <Field> = <Value>
WHERE <Condition>
DELETE FROM <Table>
WHERE <Condition>
Software Modeling
Operation
SQL
HTTP
Create
INSERT
POST
Read (Retrieve)
SELECT
GET
Update
UPDATE
PUT
Delete (Destroy)
DELETE
DELETE
Requirements Capture & Analysis
• Problem Analysis
– Ask questions about the business environment
– Use Cases for Current Business Processes
• Solution Identification
– Brainstorm: Come up with a new process that solves the
problem at hand
• Requirements Specification
– Use Cases for the new Process
– Activity Diagrams for the new Process
– Data Model for the new Process
Software Requirements
Types of requirement
• User requirements
– Statements in natural language plus diagrams of
the services the system provides and its
operational constraints. Written for customers.
• System requirements
– A structured document setting out detailed
descriptions of the system’s functions, services
and operational constraints. Defines what should
be implemented so may be part of a contract
between client and contractor.
Chapter 4 Requirements engineering
27
Readers of different types of
requirements specification
Chapter 4 Requirements engineering
28
Functional and non-functional
requirements
• Functional requirements
– Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in
particular situations.
– May state what the system should not do.
• Non-functional requirements
– Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
– Often apply to the system as a whole rather than
individual features or services.
• Domain requirements
– Constraints on the system from the domain of
Chapter 4 Requirements engineering
operation
29
Functional requirements
• Describe functionality or system services.
• Depend on the type of software, expected
users and the type of system where the
software is used.
• Functional user requirements may be highlevel statements of what the system should
do.
• Functional system requirements should
describe the system services in detail.
Chapter 4 Requirements engineering
30
Requirements imprecision
• Problems arise when requirements are not
precisely stated.
• Ambiguous requirements may be interpreted in
different ways by developers and users.
• Consider the term ‘search’ in requirement 1
– User intention – search for a patient name across all
appointments in all clinics;
– Developer interpretation – search for a patient name
in an individual clinic. User chooses clinic then search.
Chapter 4 Requirements engineering
31
Requirements completeness and
consistency
• In principle, requirements should be both complete and
consistent.
• Complete
– They should include descriptions of all facilities
required.
• Consistent
– There should be no conflicts or contradictions in
the descriptions of the system facilities.
• In practice, it is impossible to produce a complete and
consistent requirements document.
Chapter 4 Requirements engineering
32
Non-functional requirements
• These define system properties and
constraints e.g. reliability, response time and
storage requirements. Constraints are I/O
device capability, system representations, etc.
• Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
• Non-functional requirements may be more
critical than functional requirements. If these
are not met, the system may be useless.
Chapter 4 Requirements engineering
33
Types of nonfunctional requirement
Chapter 4 Requirements engineering
34
Non-functional requirements
implementation
• Non-functional requirements may affect the
overall architecture of a system rather than the
individual components.
– For example, to ensure that performance
requirements are met, you may have to organize the
system to minimize communications between
components.
• A single non-functional requirement, such as a
security requirement, may generate a number of
related functional requirements that define
system services that are required.
Chapter 4 Requirements engineering
35
Non-functional classifications
• Product requirements
– Requirements which specify that the delivered product must behave in
a particular way e.g. execution speed, reliability, etc.
• Organizational requirements
– Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation
requirements, etc.
• External requirements
– Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Chapter 4 Requirements engineering
36
Goals and requirements
• Non-functional requirements may be
– very difficult to state precisely, and
– imprecise requirements may be difficult to verify.
• Goal
– A general intention of the user such as ease of use.
• Verifiable non-functional requirement
– A statement using some measure that can be objectively tested.
• Goals are helpful to developers as they convey the intentions
of the system users.
Chapter 4 Requirements engineering
37
Usability requirements - Example
• The system should be easy to use by medical
staff and should be organized in such a way
that user errors are minimized. (Goal)
• Medical staff shall be able to use all the
system functions after four hours of training.
After this training, the average number of
errors made by experienced users shall not
exceed two per hour of system use. (Testable
non-functional requirement)
Chapter 4 Requirements engineering
38
Metrics for specifying nonfunctional
requirements
Property
Measure
Speed
Processed transactions/second
User/event response time
Screen refresh time
Size
Mbytes
Number of ROM chips
Ease of use
Training time
Number of help frames
Reliability
Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness
Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability
Percentage of target dependent statements
Number of target systems
Chapter 4 Requirements engineering
39
Case Study – 1: E-Commerce
• Customer: Medical Supplies, Inc.
–
–
–
–
250 Employees
4 distribution centers across US (CA, FL, NY, TX)
Corporate Headquarters: Scottsdale, AZ
Business: Leading distributor of medical equipment and supplies
– Problem Definition:
• Currently only supports phone and mail orders.
• Orders are processed at the headquarter and dispatched to the
distribution centers for fulfillment
• Needs online ordering system for business-to-business customers that
supports,
– shopping cart with customer specific product catalogs and payment
processing,
– order status and history lookup, and
– integration with back office ERP system.
Software Requirements
Case Study – 2: Health Insurance
• Customer: Kaiser Permanente
–
–
–
–
–
–
Medical Centers: 32
Medical Offices: 416
Physicians: 13,000 (Approximate)
Employees: 156,000 (Approximate)
Operating Income 2006: $34.4 billion
Headquarter: Oakland, CA
– Problem Definition:
• Medical Centers and Offices submit insurance claims on behalf of the patient to
claims processing center (CPC)
• CPC verifies the claims with the patients health care benefits
– Pays Medical Facility for the services, and
– sends an invoice for uncovered charges to the patient.
• Claims are settled once CPC receives payment from the patient.
• Company wants to streamline their Health Insurance Claims processing.
– Too much time is being spent in insurance claims verification and settlement.
Software Requirements

Download Report