Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
41 Cards in this Set
- Front
- Back
Systems Analysts do what? |
1. Define the problem |
|
The Systems Development Lifecycle |
planning, defining, designing, building, testing, deployment |
|
The Agile Approach |
exploration, planning, iterate until first release, production/maintenance |
|
Effective Meetings |
1. Achieve an objective that cannot be doneusing other means 2. Take up minimum amount of time 3. Involve the right people 4. Leave participants feeling it was a goodway to spend their time |
|
Request for Proposals |
Captures the Clients’ expression of a need for improvementand defines the project |
|
Sections of an RFP |
Project Overview Project Objectives Context Schedule, Constraints Client team and contact info Glossary |
|
Why is a Project Charter important? |
• Sets realistic expectations • Everyone on same page • Defines clearly what will be done/not done • Gives a name to the project & defines uniqueterms • Guides the project |
|
Project Charter |
Captures the problem and what will be doneabout it |
|
Sections of a project charter |
1. Overview Executive summary, Context, Need, Scope, Stakeholders, Objectives, Glossary 2. Approach Team organization and roles, Work Breakdown Structure, Milestones, Deliverables, Risks 3. Approval |
|
Main Elicitation techniques |
Background reading/inspection of documents • Interviews (open ended or structured) • Questionnaires • Observations • Group techniques (JAD, Participatory design,focus groups) • Contextual Design |
|
Five steps of an interview: |
Preparing for the interview Planning and scheduling the interview Opening and closing the interview Conducting the interview Following up for clarification |
|
Structured interviews |
Advantages 1. Forces an organization on the interview 2. Very goal-directed 3. Attempts to remove distortion from interviewees subjectively 4. Allows better integration of material after the interview 5. Forces the interviewee to be systematic 6. Requirements engineer identifies gaps in the knowledge which acts as a basis for questions 7. Purpose of session is clear to interviewee Disadvantages 1. Needs more preparation by the requirements engineer 2. Needs to study background material extensively 3. May overconstrain the interviewee, preventing discovery ofrequirements 4. May intimidate the interviewee |
|
Unstructured interviews |
Advantages 1. Appropriate when the RE wants to explore an issue 2. Facilitates description of domain in a way that is easy for the interviewee 3. Goal is to establish rapport and to get a broad view Disadvantages 1. Data acquired is often unrelated and difficult to integrate 2. Often exhibits lack of structure 3. Does not allow gathering of specific knowledge 4. Takes time and training to do well 5. Similar questions asked in future sessions may annoy interviewee |
|
Interviews summary |
Advantages – Access to individual stakeholders and their opinions – Rich collection of information – Ability to adapt questions to particular situations Disadvantages • Information from multiple sources, hard to analyze • Difficult to be a skilled interviewer • May intimidate the interviewee |
|
Questionnaires |
Advantages – Ability to reach a large pool of people – Uniformity of questions – Geographical distribution of stakeholders not an issue Disadvantages – Difficult to collect contextual information – Difficult to design well |
|
Observations |
Advantages – Ability to collect contextual information – Reveals details of tacit knowledge Disadvantages – Often difficult to obtain access to the customer site – Time consuming – Does not collect information on personal opinions – Easy to “go native” |
|
Group techniques |
Advantages – Bring stakeholders together! – More informal interaction than interviews Disadvantages – More difficult to deal with groups, needs a trained facilitator – Risk of groupthink |
|
Creating a Plan |
• People – leader, analysts, developers • Milestones– Define tasks to reach each milestone • Assign people to tasks • Estimate task duration • Dependencies between tasks • Check sanity & adjust |
|
Managing risks |
• Create a list of risks • Assign each a severity (impact) andprobability• How to cope with each risk?– Add coping strategies as tasks |
|
Hard vs. soft systems |
No human interaction |
|
Functional vs. non-functional |
• Functionality • Physical environment • Interfaces • Users and human factors • Documentation • Data • Resources • Security • Quality assurance |
|
Functionality |
What will the system do? • When will de system do it? • Are there several modes of operation? • How and when can the system be changed orenhanced? |
|
Users and human factors |
• Who will use the system? • Will there be several types of users? • What is the skill level of each type of user? • What kind of training will be required for eachtype of user? • How difficult will it be for a user to misuse thesystem? |
|
Data |
• For both input and output, what should theformat or the data be? • How often will they be received or sent? • How accurate must they be? • To what degree of precision must the calculationsbe made? • How much data flow through the system? • Are there confidentiality concerns about the data? |
|
Physical environment |
• Where is the equipment to function? • Is there one location or several? • Are there any environmental restrictions,such as temperature, humidity or magneticinterference? |
|
Interfaces |
Is the input coming from one or more othersystems? • Is the output going to one or more other systems? • Is there a prescribed way in which the data must beformatted to effectively interface with othersystems? • Is there a prescribed medium that the data must use(e.g. reports by mail, meetings, website)? |
|
Documentation |
How much documentation is required? • Should it be on-line in book format orboth? |
|
Resources |
• What materials, personnel, or other resources arerequired to build, use, and maintain the system? • What skills must the developers have? • How much physical space will be taken up by thesystem? • Is there a prescribed timetable for development? • Is there a limit on the amount of money to be spent ondevelopment or on hardware and software? |
|
Security |
Must access to the system or information becontrolled? • How will one user's data be isolated fromothers? • How will user programs be isolated from otherprograms and from the operating system? • How often will the system be backed up? |
|
Quality assurance |
What are the requirements for reliability, availability,maintainability, security? • What is the prescribed mean time between failures? • Is there a maximum time allowed for restarting thesystem after a failure? • What efficiency measures will apply to resource usageand response time? |
|
What makes a SRS high quality? |
Unambiguous • Complete • Verifiable • Consistent • Modifiable • Traceable • Ranked for importance • Correct |
|
Sources of non-functional requirements |
• Project charter • Your interview notes • Use cases • UI Prototype development • Business processes • Explicit interviews or questionnaires |
|
How to write good non-functional reqs? |
• Must be testable |
|
Agile vs. “traditional” Modeling |
The “agile”: A practical method formodeling to create software systems • Based on best practices • Light-weight– ‘just enough’ to get the job done– don’t model for the sake of modeling |
|
Use Case Modeling |
interaction between actors |
|
Domain Modeling: Entity RelationshipDiagrams |
1 to 1 |
|
The use case specification should include |
Actors – primary, possibly secondary • Preconditions – What has to have happenedfirst • Steps (numbered and may have sub-steps)– List the actions of the actor • Success condition – What has to result for thisto be successful • Alternate paths (if any)– Branch off at the appropriate numbered step |
|
Data Flow Diagram |
verbs are in bubbles |
|
Context Diagram(DFD 0) |
• The highest level in a data flow diagram • Contains only one process, representingthe entire system • The process is given the number 0 • All external entities, as well as major dataflows are shown |
|
DFD 1 |
drilldown into system in DFD 0 |
|
Typical errors in a data flow diagram |
process has no output external entity should not correct directly to data store data store does not connect directly to data store |