LEC 2 Flashcards

1
Q
  • consists of those activities that enable a person to understand and specify what the new system should accomplish.
  • What is required for the new system to solve the problem
A

Systems Analysis

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q
  • those system development activities that enable a person to describe in detail how the resulting information system will actually be implemented
  • How the system will operate to solve the problem
A

System Design

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

(READ)
In a nutshell, systems analysis and design provides the tools and techniques you need as an information system developer to complete the development process:

  1. Understand the need (business need)
  2. Capture the vision
  3. Define a solution
  4. Communicate the vision and the solution
  5. Build the solution or direct others in building the solution
  6. Confirm that the solution meets the need
  7. Launch the solution application
A

Systems Analysis and System Design

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

is a framework that identifies all the activities required to research, build, deploy and often maintain an information system

A

The System Development Life Cycle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

○ Identify the problem and obtain approval
○ Plan and monitor the project
○ Discover and understand details
○ Design system components
○ Build, test, and integrate system components
○ Complete system tests and deploy the solution

A

Core Processes of the SDLC

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

● This is a set of comprehensive guidelines for carrying out all the activities of each core process of the SDLC.
● Also termed as system development process.

A

System Development Methodology

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

● An information system development process that emphasizes flexibility and rapid response to anticipate new and changing requirements during development.
● The basic philosophy is that neither team members nor the users
completely understand the problems and complexities of a new
system

A

Agile Methodology

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

All the activities of the new system must perform or support and constraints that the new system must meet (FURPS)

A

System Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

○ The activities the system must perform to support the user’s work
○ Example requirements for a payroll system:
■ Generate electronic fund transfers, calculate commission amounts, calculate payroll taxes, maintain employee-dependent information, report tax deduction

A

Functional requirements (F)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

○ Required characteristics other than the activities it must perform or support
○ URPS - usability requirements, reliability requirements, performance, security

A

Non-Functional requirements (URPS)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

○ The requirements for operational characteristics related to users such as the user interface, related work procedures, online help and documentation
○ Example: UI of an app should behave similarly to other apps when responding to gestures, format, color scheme, company logo, multi-lingual support

A

Usability Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

○ The requirements that describe the dependability of a system - how often the system exhibits such behaviors as service outages and incorrect processing and how it detects and recovers from those problems.

A

Reliability Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

○ The requirements that describe operational characteristics related to measures of workload, such as throughput and response time
○ Example: .5 second response time to all button presses, the server support for 100 simultaneous client sessions with the same response time.

A

Performance Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

○ The requirements that describe how access to the application can be controlled and how data will be protected during storage and transmission
○ Example: password protected, encrypted data, use HTTPS for communication among clients and server

A

Security Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

is an extension of FURPS that includes design constraints as well
as implementation, system interface, physical and supportability
requirements.

A

FURPS+

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

○Describe restrictions to which the hardware and software must adhere.
○ Example:
■ a cell phone application might be required to use the Android operating system,
■ consume no more than 30MB of flash memory storage,
■ consume no more than 10 MB of system memory while running,
■ and operate on CPUs rated at 1 GHz or highe

A

Design Constraints

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

○ Describe constraints such as required programming languages and tools, documentation method, level of detail , specific communication protocol for distributed components

A

Implementation requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

○ Describe interactions among systems.
○ Example:
■ Financial reporting system for publicly traded company must generate data for SEC in a specific XML format

A

Interface requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

○ Describe such characteristics of hardware as size, weight, power consumption and operating conditions
○ Example:
■ A system that supports battlefield communication might have requirements as weighing less than 200 grams, ebing no larger than 5 cm, operating 48 hours on a fully charged 1200 milliwatt lithium ion battery

A

Physical requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

○ This describes how a system is installed, configured, monitored, and updated.
○ Example: Requirements for a game installed on a home PC might include automatic configuration to maximize performance on existing hardware, error reporting, and download of updates from a support server

A

Supportability Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

a representation of some aspect of the system being built

A

Model

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Types of Models

A

Textual Model
Graphical Model
Mathematical Model

23
Q

something written down, described

A

Textual Model

24
Q

diagram, schematic

A

Graphical Model

25
Q

formula, statistics, algorithm

A

Mathematical Model

26
Q

○ Standard graphical modeling symbols / terminology used for information systems

A

Unified Modeling Language (UML)

27
Q

● Learning from the modeling process
● Reducing complexity by abstraction
● Remembering all the details
● Communicating with other development team members
● Communicating with a variety of users and stakeholders
● Documenting what was done for future maintenance/ enhancements

A

Reasons for Modeling

28
Q

● are the primary source of information for system requirements.
● These are all the people who have an interest in the successful
implementation of the system

A

Stakeholders

29
Q

○ Persons within the organization who interact with the system or have a significant interest in its operation or success

A

Internal stakeholders

30
Q

○ Persons outside the organization’s control and influence who interact with the system or have a significant interest in its operation or success

A

External stakeholders

31
Q

○ Persons who regularly interact with a system in the course of their jobs or lives

A

Operational stakeholders

32
Q

○ Persons who don’t interact directly with the system but who either use information produced by the system or have significant financial or other interest in its operation and success

A

Executive stakeholders

33
Q

● Interviewing users and other stakeholders
● Distributing and collecting questionnaires
● Reviewing inputs, outputs and documentation
● Observing and documenting business procedures
● Researching vendor solutions
● Collecting active user comments and suggestions

A

Information Gathering Techniques

34
Q

● Prepare detailed questions
● Meet with individuals or group of users
● Obtain and discuss answers to questions
● Document the answers
● Follow up as needed in the future meetings or interviews

A

Interviewing Users and Other Stakeholders

35
Q

● Observe and Document Business Processes
○ Watch and Learn
○ Document with Activity Diagram
● Research Vendor Solutions
○ See what others have done for similar situations
● Collect Active User Comments and Suggestions
○ Feedback on models and tests

A

Additional Techniques

36
Q

● describes a specific
business goal to be satisfied by the
system to be built.
● Graphically, it is an oval with a
name, which looks simple but is yet
the most commonly used tool in
managing business goals or project
goals.

A

Use Cases

37
Q

●is a kind of Unified Modeling Language (UML) diagram created for requirement elicitation.
● provides a graphical overview of goals
(modeled by use cases) users (represented by actors) want to
achieve by using the system.
● usually simple. It does not show the detail of the use cases:
○ It only summarizes some of the relationships between use cases,
actors, and systems.
○ It does not show the order in which steps are performed to achieve the goals of each use case.
● should be simple and contains only a few shapes.

A

Use Case Diagram

38
Q

● Use cases represent only the functional requirements of a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented
separately, again, with other UML diagrams

A

UML Diagram Type

39
Q

Systems
Actor
Use Case
Relationships
- Include
- Extend
- Generalization

A

Use Case Diagram Elements

40
Q
  • Whatever you are developing.
  • It could be a website, software component, business process or an
    app
  • Represented by a rectangle with a name at the top
  • Anything within the rectangle happens inside the system. Anything outside the rectangle, happens outside the system.
A

Systems

41
Q
  • Stick figure
  • Someone or something that uses the system to achieve a goal
  • It could be a person, organization, another system or an external device
  • Actors are external objects to be placed outside the system
  • Names should be categorical
  • Primary actor initiates the system (left)
  • Secondary actor is more reactionary (right)
A

Actor

42
Q
  • Oval in Shape
  • Represents an action that accomplishes some sort of task
    within the system
  • Start with a verb and reinforce an action that takes place. It should be sufficiently descriptive
  • Put the use cases in a logical order when possible
A

Use Case

43
Q

Signifies a basic communication or interaction

A

Association (Relationships)

44
Q
  • Shows dependency between a base use case and an this use case
  • Everytime that a base use case is executed, this use case is also executed
  • The base use case requires an this use case in order to be complete
  • Represented by a dashed-line from the base use case to the this use case.
A

Include (Relationships)

45
Q
  • Has a base use case and an have this use
    case
  • When the base use case is executed, this use case will happen sometimes but not every time.
  • This use case will only happen if certain criteria are met
  • Draw a dashed line from this use case to the base use case
  • Note: Include Happens everytime, Extend happens sometimes. Arrow points in opposite directions.
A

Extend (Relationships)

46
Q
  • Also known as inheritance
  • Each child shares the common behaviors of the parent, but each child adds something more on its own
A

Generalization (Relationships)

47
Q

● is a great way of opening discussion with stakeholders for ensuring
the development team knows what stakeholders want
● created by the product owner capture “who”, “what” and “why” of a requirement simply and concisely, which is typically written in natural language in a non-technical format.
● Agile development has entered into the mainstream of development approach hand-in-hand with user stories for requirement discovery

A

User Story

48
Q

● One short sentence in the everyday language of the end user that states what a user does as part of his or her work
● are basic concepts in Agile development because they focus on simplicity, value added and user collaboration.
● They document the functional requirements focusing on who, what and why for each function.
● The standard template for a user story:
○ “As a <role>, I want to <goal> so that <reason>”</reason></goal></role>

A

User Story

49
Q

● As a teller, I want to make a deposit to quickly serve more customers
● As a teller, I want to balance the cash drawer to assure there were no error
● As a bank customer,I want to withdraw cash and feel confident the stack of cash I get is the correct amount
● As a bank customer, I want to deposit a check and feel confident the deposit is recorded correctly.

A

User Stories Examples

50
Q

● A final part of a user story is the
● These indicate the features that must be present for the user to be satisfied with the resulting implementation
● They focus on functionality, not on features or user-interface design

A

Acceptance Criteria

51
Q
  1. Customer lookup must be by name or by account number
  2. It would be nice to display photo and signature of customer
  3. Any check hold requirements must be indicated
  4. Current balance and new balance must be displayed
A

Acceptance Criteria for the user story “bank teller making a deposit”

52
Q

User Story
- As a teller, I want to make a deposit to quickly serve more customers

Acceptance Criteria
- Customer lookup must be by name or by account number
- Nice to display a photo and signature of customer
- Any check hold requirements must be indicated
- Current Balance and new balance must be displayed

A

User Story and Acceptance Criteria

53
Q

User Story
- As a shipping clerk, I want to ship an order as accurately as possible as soon as the order details are available

Acceptance Criteria
- Available order details must pop up on the screen when available
- Portable display and scan device would cut time in half
- Sort the items by bin location
- Indicate number of items in stock for each item and mark backorder for those not available
- Recommend shipper based on weight, size and location
- Print out shipping label for selected shipper

A

User Story and Acceptance Criteria

54
Q

● As a user, I can register to the application by entering my email, password, and confirming my password
● As a user, I can upload a profile picture and add my name into my account
● As a user, I can view my personal details
● As a teller, I want to be able to find clients by last name, so I can find their profile easier
● As a shopper, I want to view a list of products so I can select some to purchase
● As a shopper, I want to view my cart so I can make adjustments prior to checkout
● As an administrator, I want to modify the list of products so I can adjust our offerings over time
● As a finance employee, I want to view analytics about orders and revenue so I can see how we’re tracking against our goals

A

Other Examples of User Stories