Week 3 Flashcards
System Development Life Cycle
Includes a detailed plan of all activities needed for building, developing modifying and maintaining an information system
SDLC
Planning
Analysis
Design
Implementation
Primary focus of Analysis
Understanding business functions and developing system requirements
Understanding the problem
Breaking a whole part into parts with the intent of understanding the part’s nature, function and interrelationship
Skills Needed for Analysis in Analysis
Fact finding for investigation
Learn details of business
Knowledgeable as business domain users to build credibility
Brings fresh perspective to the problem (analyst from different business domain)
Communication
Requirement
A statement (with context) of what the system must do or what characteristics it needs to have
Detailed enough to prevent misunderstanding
User Requirement Gathering - Business
What the business needs :-
Functions performed
Operating environment
Current problems that have driven the need for a new system
User Requirement Gathering - User Needs
What the users see and do to support business needs
In what circumstances things are done
Types of System Requirements
Functional
Non-functional
Functional Requirements
Activities that the system must perform
They are based on business rules and processes
Non-functional requirements
Characteristics that the system must provide or support
try to fulfill these requirements as much as you can
FURPS
Functional Usability requirements Reliability requirements Performance requirements Securityrequirements
Functional requirements
business tasks that users must perform using the system
Usability requirements
Represent operational characteristics
-Like user interface, menu structure, color choice, online help
Reliability requirements
- Shows dependability
- E.g. services not available
Performance requirements
- Response time (e.g. 1 second for logon)
- Throughput (e.g. can support 100 students’ usage of Moodle)
Security requirements
–Password protection
- Encryption
- Unauthorize access
FURPS +
Additional requirements beyond FURPS
Design constraints (hardware or software restrictions)
Implementation requirements (programming language and tools)
Interface requirements (interactions among system)
Physical Requirements (hardware characteristics)
Supportability requirements (about the system installation, configuration and upgrade)
Stakeholders
Any person who has an interest (stake) in the successful implementation of the system
Direct or indirect relationship with the system
Internal Stakeholders
Persons within the organisation
External stakeholders
Persons outside the organisation but have an interest
Operational stakeholderst
Persons who regularly interact with the system
Executive stakeholders
Persons who dont directly interact but use the information or have financial interest
Latents
High interest low interest
Promoters
High influence high interest
Apathetics
Low influence low interest
Defenders
Low influence high interest
Techniques
Technique 1: Interview
Technique 2: Distributing and collecting questionnaires
Technique 3: Reviewing inputs, outputs, and documentation
Technique 4: Observing and documenting business procedures
Technique 5: Researching vendor solutions
Technique 6: Collecting active user comments, and suggestions
Interview
Conducted at users workplace (see how work is done)
Conducted away (to avoid work related interruptions)
Structured interview
List of predetermined questions
Semi-structured
Using some predetermined questions but allowing further elaboration and discovery
Unstructured
Mainly using open questions
Question types
Closed ended questions -> yes/no limit discussion and data elicitation
Open ended questions -> enable exploring, probing and learning on complex topics
Interview purpose
Understand the needs and expectations
raise awareness of the project
Interview advantages
Effective way to understand
business functions and rules
Get a first hand impression of
business requirements
Create bonds
Interview disadvantages
Time consuming and resource expensive
What people say is not always what they really do
Questionnaires
paper or electronic
allows gathering of data from a large group
annonymous
standardized
Advantages
Cover a wide spectrum of people
Disadvantags
Low response rate
Questions may not be well understood
Review Reports, Forms and Procedure Descriptions
Document analysis of existing internal business documents/ procedures
What to look for in reviewing internal documents
identify business rules, discrepancies, redundancies
cautious of outdated material
preliminary understanding of processes
use as guideline for interviews
What to look for in reviewing external documents
industry wide practices
trade publications
Observations
to obtain discrepancy between documentation and what is actually performed
Passive observation
watching and listening to users in their environments
Active observation
asking users questions and having a conversation
Hawthorne (observer) effect
If users are aware of being observed, their behavior may be affected
Research Vendor Solutions
Many problems already solved (prepacked solutions)
Positive contributions (new ideas, new state of art tech, cheaper and less risky)
Danger
purchase a solution before understanding the problem
may not address all requirements
vendor support, upgrade issues
Techniques in Vendor Research
Technical specifications from vendor (for integration with pre-existing system)
Demo or trial system
References of existing clients
On-site visits
Printout of screens and reports
RFP - request for proposal
Collective ACTIVE USER COMMENTS and suggestions
Feedback on models and tests
Users know it and when they see it
Extra Techniques: Workshops
Get all stakeholders in a room for a couple of days and facilitate discussion
Build models with everyone there
People bounce ideas of each other
Requires a conference room, whiteboard facilitator and a scribe
Problems of Workshops
Can be very difficult to organise
Particularly when senior people are involved
Requires taking people off work for a week or so
Requirements Specification Report
Document or report that communicates the design that you are proposing
describes understanding of business problem
Scope
Critical concept that defines the conceptual boundary of the project
everything inside the scope needs to be designed
impacts size, cost, complexity and time
disagreement between clients and designers due to scope
Assumptions
Results from gaps in understanding of the design problem
should be minimal or none at all
gap should be clarified with client
Requirements Specification
The remainder of the report deals with various models making up the design
Unified Modelling Language
UML is the standard set of model constructs and notations by the Object Management Group
Analyst and end users can depict and understand a variety of specific models used in SAD
Why are models developed?
models are used to converse with clients to clarify requirements
designers learn more about expectations and requirements
let designers study certain properties
learning mechanism
products or systems are built based on lessons learned from modelling exercise
Models in System Analysis
Models are constructed to represent requirements of the system
Examples of models
Use cases
class diagrams
sequence diagrams
activity diagrams
Activities of Analysis
Gather detailed information
Define (functional and non-functional) requirements
Prioritise requirements
Develop user interface dialogs
Evaluate requirements with users
