Week 1 - Introduction to Business Requirements Modelling, Week 2 - Requirements Process, Week 3 - Requirements Elicitation, Week 4 - Business Process Modelling, Week 5 - Data Modelling, Week 7 - Object Oriented Modelling, Week 6 - Software Requiremen...

SRS (Purpose)

- To analyse the elicited requirements. - Define what designers/developers have to build. - Verification against the delivered system. - Validating that they are indeed what stakeholders want. - Baseline for evaluating the software. - Support for testing (verification and validation).

Requirements (Engineering/Development/Gathering) Process

- To find the correct and complete requirements, we need some kind of *orderly process*. And hence we need Requirements Process. - *Process* is a set of steps (phases) that a software program goes through when developed. - It is a *structure* imposed on the development of a software product

Use Case Narratives

- Use Case Narrative Template (refer to a separate document available on uts online and understand each section). *MUST READ EACH SECTION.* - Detail "Buy Ticket" Scenario or Narrative. Refer to a separate document on uts online to see the narrative for Buy Ticket use case.

User Stories (Estimation of effort)

Common methods to estimate the time/effort to complete each user story include: - T-shirt sizes (S, M, L, XL and XXL) - Powers of 2 (1, 2, 4, 8) - The Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) - Story Point (1 to 10) - (method used in this subject)

Level 1 Diagram

Identify all the business processes (main functionalities/features/work activities) within the System

Software Requirements Specification

It is a document that provides the detailed description of what the system should do. - structured document setting out the system services and capabilities in detail. - sometimes called as functional specification. - often serves as a contract between the client and vendor.

Dotted Arrow

Message Flow - Flow of messages between two participants

Agile System Development Process

a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change. It is a conceptual framework that focuses on delivering working software with the minimum amount of work.

Waterfall System Development Process

a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. It maintains that one should move to a phase only when its preceding phase is reviewed and verified. One phase is completed in its entirety before moving on to the next phase. And you rarely revisit a phase once it is completed

Requirements Modelling

developing a set of diagrams known as requirements models, each of which focuses on a different aspect of the users' needs. e.g. - Business Process Modelling with BPMN - Data Modelling with ERD - Object Oriented Modelling with UML

Users (Stakeholder Classes)

have an interest in having a product that does their work correctly. They are people who will ultimately be hands on operators of your product

Measurable

this answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete

Workshop Fundamentals

- A workshop may be used to *scope, discover, define, refine, update, prioritize* and reach closure on *requirements* for the target system. - A workshop may be used to *generate ideas for new features or products*, to reach consensus on a topic or conflicting views, or to review requirements. - Organised process: uses techniques such as brain storming, top down analysis, etc. - Documented approach: output of each session is documented in such a way to make it easy to read and understand and agree upon.

Relationship

- Connects entities to each other - It is an association among two or more entities - A relationship is indicated by a *verb* connecting two or more entities - Are significant business associations between entities

Circle with open centre

Event - Something that happens during the course of the business process - Affect the flow of the process - Usually have a cause (trigger) - Usually have an impact (result) Three types: - Start - Intermediate - End

Dotted line

Association - Associate information with flow objects

Agile Card Wall

Backlog | Planned | Ready | In progress | QA | Done Each column contains user stories

Dotted rectangle

Group - Grouping activity that does not affect the sequence flow - can be used for documentation or analyses purposes - Can be used to identify activities of a distributed transaction that is shown across pools

Role of Business Analyst

Tasks - Business/domain knowledge - Problems and needs of business (requirements) - Manage stakeholders and communication - Modelling - Review business requirements - Obtain Sign Off - Recommend solutions - Software testing

Object Oriented Modeling Language

The Unified Modelling Language

Iterative and incremental development (Agile)

The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through cross-discipline work, from the requirements to the deployment.

Specific

a good requirement is specific and not generic. It should not be open to mis-interpretation when read by others

Sprint (agile - scrum)

the basic unit of development in Scrum. The sprint is a "timeboxed" effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical. Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Functional Requirements

(things product must do) - describe the behavior and information that the solution will manage. - They describe *capabilities* the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses Examples: - The software system should be able to produce a monthly sales report for a given month... - The system shall enable hotel guests to book a room online

Requirements Management Tool (Requirements Process Stages)

- Requirements Backlog - Burndown charts - Requirements Register or Excel Spreadsheet - IBM JazzHub - JIRA

Entity Relationship Diagram (Data Model)

- an abstraction of the data the organisation works with - a way to organise the data of interest into a standardised structure

Stakeholders Analysis (Why do it?)

- involves identifying all the relevant stakeholders and understanding their needs (and any issues with current system). - It is the review and consideration of the impact stakeholders have on your business. Companies need to understand the *interests* of each stakeholder. - To *understand the importance and influence of individual stakeholders* on the project. - To utilise the vast amount of information and knowledge that stakeholders hold to find workable, efficient and sustainable solutions. - *To Gain support* from powerful stakeholders which can help you to win more resources - this makes it more likely that your projects will have less obstacles and conflicts and hence be successful.

Agile SRS

1. Document Management 1.1 Revision History 1.2 Intended Audience 1.3 Reference Documents 1.4 Glossary 2. Introduction 2.1 Document Purpose 2.2 Project Purpose 2.3 Project Scope 2.3.1 In Scope 2.3.2 Out of Scope 2.4 Assumptions 3. Functional Requirements 3.1 User Story Map 3.2 User Stories and Use Cases 3.2.1 Use Case: Name of the Use Case 3.2.2 Use Case: 3.3 Sequence Diagrams 4. Data Requirements 4.1 Class Diagram 4.2 State Transition Diagram 5. Non-functional requirements5.1 User Interface Requirements 5.2 Security Requirements 5.3 Performance Requirements 6. Bibliography 7. Appendices

Rectangle with curved corners

Activity - A generic term for work - Can be atomic or non-atomic (compound) Types: - Process - Sub-Process - Tasks Processes are different, they are either unbound or contained within a Pool

ATM Process Model

Context: - Identify all the External Entities + information that flows between the ATM System and Entities Level 1: Identify all business processes within the ATM System: - 01 Withdraw money - 02 Transfer money - 03 Deposit money - 04 Change PIN Level 2: - Detail/model all sub-processes and tasks/activities within each process identified at Level 1. Identify all the tasks from the start to end required to complete each Level 1 process and draw one separate diagram for each Level 1 process

User Story

Example: *As a* passenger, *I want* to buy a ticket via Online Ticketing System *so that* I can travel from one city to another city in Australia. Remember -> A User Story can be detailed in terms of 1 or many Use Cases. Or many user stories can be detailed in one use case. The relationship depends on a number of factors. Based on this User Story you have further conversations with the user or proxy user and identify the additional details.

Stakeholders list

Name | Position | Project role | Contact Information | Level of Interest | Level of Influence | Potential Management Strategies

Subject Matter Experts (Stakeholder Classes)

People who have specialised knowledge of the business subject, individual with in-depth knowledge of a topic relevant to the business need or solution scope

Empathy Map

Person Known to group (title) | Seeing | saying | Doing | Feeling | Hearing

Single column table

Pool - Participant in a Process - Swimlane - Graphical container for partitioning a set of activities

Objects

Represent real-world things Contains: - Methods or processes - Attributes or data

Realistic

answers whether the requirement is realistic to deliver when considering other constraints of the project and requirements. Are the requirements and other project constraints in their entirety, able to be met?

Customer (Stakeholder Classes)

buys the product once it is developed. A customer is a stakeholder outside the boundary of a given organization or organizational unit. Know this person well to understand what he/she finds valuable and what appeals to them

Requirements Verification and Validation

checking that the documented requirements and models are consistent and meet stakeholder needs.

Non-functional Requirements

(qualities product must have) - capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. - They are also known as quality or supplementary requirements. These can include requirements related to *capacity, speed, safety, security, availability* and the information architecture and presentation of the user interface. Examples include software *performance* requirements, external *interface* requirements, software design constraints and software quality attributes. Examples: - The software system should be able to produce a monthly sales report for a given month in less than 5 seconds... - The software system should be able to produce a monthly sales report for a given month in less than 5 seconds and display it on iPad... - The system shall be able to process 100 payment transactions per second

Advantages of Prototypes

+ A prototype allows for *early user interaction and feedback*. + can be an inexpensive means to quickly *uncover and confirm a variety of requirements.* + Supports users who are more comfortable and effective at articulating their needs by using pictures, as prototyping lets them *"see" the future system's interface.* + Provides a vehicle for designers and developers to learn about the users' interface needs and to evolve system requirements.

Advantages of Interviews

+ Allows the interviewer and participant to have *full discussions and explanations* of the questions and answers. + Personal contact allows responsiveness and adapting to what the user says. + Analyst can probe in *greater depth* than any other methods of elicitation + Allows interviewees to *express opinions in private* that they may be reluctant to express in public.

Advantages of Surveys

+ An *economical* and *quick* method of gathering data from a *large sample* + Can *reach many people with low resource* + Used for answering specific questions. + Can be *administered remotely* + Depending on how well it is designed, the results can be analysed easily by software applications. + Effective and efficient when stakeholders are not located in one location.

Advantages of Observation

+ Provides *first hand experience* of the way the current system works + Data is collected in *real time* and can have a high level of validity + Can be used to *verify information* from other sources or to look for exceptions + Baseline data about the performance of the existing system and of users can be collected

Advantages of Workshops

+ Workshop sessions are very successful in *reducing project development efforts and shortening the schedule.* + Used to *generate ideas* for new features or products. + To *reach consensus* on a topic or conflicting views. + Is able to gauge reaction to stimulus material (e.g. storyboards, screenshots). + A requirements workshop provides a *means for stakeholders to collaborate*, make decisions and *gain a mutual understanding of requirements*.

Extension Use Case

- 'Extends' - An extending or extension use case extends a base use case by naming the base use case and defining the circumstances under which it interrupts the base use case - The extending use case specifies some internal condition in the base use case and a triggering condition. Behavior runs through the base use case until the condition occurs, at which point it continues in the extending use case. When the extending use case finishes, the behavior picks up in the base use case where it left off. - Links a use case to another use case describing a variation from standard behavior - Use when the system takes a different behavior - the section in use case narrative defines alternative paths through the use case. Often, extensions are used for error handling; but extensions are also used to describe successful but secondary paths

Generalised Use Case

- 'Generalise' or 'Inherits' -- The general use case generalises the specific one -- Defines a link between a general and more specific use case -- The (specialising) child should be of a "similar species" to that of the (general) parent. -- A generalisation relationship between use case implies that the child use case contains all the attributes, sequences of behaviour, and extension points defined in the parent use case, and participates in all the relationships of the parent use case.

Types (Cardinality)

- *1:0* (Employee : Department) An Employee may or may not be assigned to a Department - *1:1* (must be one - Manager : Department) Each Manager heads one Department and vice versa - *1:N* (Company : Addresses) Each company has many addresses - *M:N* (Tutor : Subject) One Tutor teaches many Subjects, one Subject has many Tutors - *M:N* (Student : Subject) One Student enrolls in many Subjects, one Subject has many Students

Basic constructs of ERD

- *Entities* are anything about whom you want to record or store data; concepts, real or abstract, about which information is collected. - *Relationships* are associations between the entities. - *Attributes* are properties which describe the entities. - *Cardinality* is a numerical relationship between two entities

Product Owner

- *Represents the stakeholders* and is the voice of the customer and is accountable for ensuring that the team delivers value to the business. - Writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. - Defines the features of the product. - Decides on release date and content. - Responsible for the profitability of the product (ROI). - *Prioritizes features* according to market value in the Product Backlog Items. - Adjusts features and priority every iteration, as needed. - Accepts or rejects work results

User Stories (Importance/Prioritisation of user stories)

- *Requirements prioritisation* is used in software development for determining which candidate requirements of a software product should be included in a certain release. - Requirements (user stories) are also prioritized to minimise risk during development so that the *most important or high-risk requirements (user stories) are implemented first.* - Remember, the Product Owner prioritises the user stories and decides on which user stories will be included in a certain release in consultation with the development team. Please watch "Backlog Refinement Meeting" video available on UTS Online

Attributes (Example)

- *Student (Entity)*: Student Id, Name, DOB, etc - *Order* (Entity): Order number, Quantity, Amount, etc - *Staff* (Entity): Staff Id, Name, Department, etc - Do not make an exhaustive list of attributes for each entity - Instead store only those attributes that are important to the organisation -- and the ones that are in scope of that particular project. - Each instance of an entity will become a record or row in a table in a database. -- (for example, each individual student instance)

Identifying and Understanding stakeholders (Stakeholder Analysis)

- *Who has an interest or can influence or be affected by the business transformation or changes or requirements? Below are some questions to consider when analysing the impact of new changes.* -- Who is the new change and business transformation going to affect (who all will be impacted?)? -- Who and how are you going to communicate these changes/requirements to the stakeholders? What is the communications plan? -- Who are critical to this business transformation? Who can influence? -- Who is paying for the project? -- Who will be managing, reviewing and signing off? - *Stakeholders analysis/identification techniques:* -- *Technique1*: stakeholders list/map/register and -- *Technique2*: empathy map

Surveys/Questionnaires

- A document containing a number of standard questions that can be sent to individuals to obtain information from a *large number of people* or when the people are geographically dispersed. - So, you could send these list of questions to your stakeholders asking them about the new system or the changes to the existing system - Can collect both quantitative and qualitative data. - They are also appropriate for systems that will be used by the general public and where the analyst has to investigate all the types of users of the system.

Process Decomposition

- A large or complex process is more easily understood when broken down using ___________ ______________ - Decomposition is the process of starting at a high level and dividing entities into smaller and smaller related parts. - The main purpose of it is to break up a large or complex business process into smaller and more manageable chunks/components (sub-processes and tasks). -- It therefore facilitates understanding of the business process and hence is a useful tool in conducting analysis and design

SRS (Role and Purpose)

- A legal document. A contractual device for judging the completion of the specified job. - Functional device for improving the understanding of the customer's real needs (both in business and technical terms). - So, it is a communication device that conveys an understanding between different teams in the software development process. - Used as basis for a user manual. - Statement of commitment. Validation device for validating the requirements stated in a formal manner. - Used to develop test cases.

Prototype

- A prototype is an *initial working model* of a larger, more complex entity, usually a program with limited functionality that is built to test out some aspect of *how the final system will work (and look like)* and then present it to the stakeholders. - Prototypes may be constructed with various objectives in mind: -- To investigate user requirements -- To test specific concept or verify an approach -- To focus on human-computer interface --- Investigate input and output and its form --- Investigate most suitable interface

Storyboard/Wireframes (UI flos)

- A series of drawings used mostly for *identifying user interfaces*; screens that the software will display are drawn. - User interface-flow diagrams (Storyboards/Wireframes) offer a high-level view of the interface of a system, you can quickly gain an understanding of *how the system is expected to work*. It puts you in a position where you can *validate the overall flow* of your application's user interface. For example, does the flow make sense? - User interface-flow diagrams are typically used for one of the two purposes. First, they are used to *model the interactions* that users have with your software, as defined in a single use case. Second, they enable you to gain a *high-level overview of the user interface* for your application.

Sprints

- A sprint (or iteration) is the basic unit of development in Scrum. Scrum projects make progress in a series of "sprints". -- Analogous to Extreme Programming iterations - Typical duration is 2-4 weeks or a calendar month at most - A constant duration leads to a better rhythm. - Product is designed, coded, and tested during the sprint. - Each sprint starts with a sprint planning event, the aim of which is to define a sprint backlog, where the work for the sprint is identified and an estimated commitment for the sprint goal is made. - Each sprint ends with a sprint review and a sprint retrospective, where the progress is reviewed and lessons for the next sprint are identified.

Workshop (Focus Groups)

- A technique used to expedite requirements elicitation, also referred to as "Joint Application Development" or "focused groups". - The objective is to compress all of the activities involved in other fact finding techniques into a shorter series of workshop sessions with users and project team members. - These sessions are usually conducted in special rooms with supporting facilities: overhead projector, a white board, flip charts, adequate workspace for the participants.

Use cases (Use case)

- A use case is a generalized description of a set of interactions between the system and one or more actors. A use case describes a sequence of actions performed by a system for a specific goal. The system functionalities are captured in use cases. - A use case is drawn as a horizontal ellipse/oval in a use case diagram. Use case name begins with a verb.

Attributes

- All Entities have attributes (properties) that *describe the characteristics or are a description* of an entity. -- For example, a Student entity has Student Id, Name, Address, etc., as its attributes. - All *instances* of an Entity type/set have the same attributes. -- For example, all Students will have student id, name, address , etc attributes. - However the *values* of the Attributes will vary for each instance. -- For e.g., the student ids and student names will be different for each student instance. - Attributes will become *columns* in a table in database

Empathy Map

- An empathy map is a collaborative tool teams can use to gain a *deeper insight into their customers*. It is used to understand what is it that motivates the client (or a particular key stakeholder). - Empathy Mapping helps us consider *how other people are thinking and feeling* (about this business transformation or new system/process). An empathy map is a collaborative tool that *puts us in the shoes of our clients*. - An empathy map consists of a simple face surrounded by six sections: 1. Think & Feel 2. Hear 3. See 4. Say & Do 5. Pain 6. Gain - Empathy maps can be used whenever you find a need *to immerse yourself in a user's environment* and try to understand as to what does that user/stakeholder think about the new system

Entity Types

- An entity is a place, person, thing or an event or a concept about which we wish to record information. - Entities will become a table in a database, one table for each entity. - Entities can be classified into different types. - Entity Types classify things about which we want to store data: e.g. -- *Places* - e.g. country, park, shopping centre -- *People* - e.g. customer, student, employee -- *Things* - e.g. product, vehicle, building -- *Events* - e.g. a purchase, accident, treatment -- *Concepts* - e.g. law, crime, tax, fault

Stakeholders

- An individual, team or organisation who have interest in, or can influence or be affected by, or participate in the development of requirements and relative software system projects - Stakeholder have different roles based on their interest and responsibility in an organisation - Failure to discover all stakeholders can mean failure to discover all their needs

Stakeholders

- An individual, team or organisation who have interest in, or participate in the development of requirements and relative software system - have different roles based on their interest and responsibility in an organisation - Project Manager, Business Analyst, Sponsor, End User, Owner, Subject Matter Expert, etc - Failure to discover can mean failure to discover all their needs

Interview

- An interview is a systematic approach designed to *elicit information from a person or group of people* in an informal or formal setting by talking to an interviewee, asking relevant questions and documenting the responses. - In an interview, the interviewer formally or informally *directs questions to a stakeholder* in order to obtain answers that will be used to create formal requirements. - *One-on-one interviews* are typically most common. - In a *group interview* (with more than one interviewee in attendance) the interviewer must be careful to elicit responses from all attendees - The most widely used elicitation and fact finding technique and requires the most skill and sensitivity. - Conducting an interview requires good planning, good interpersonal skills and an alert and responsive frame of mind. - One of the key goals of interviewing is to ensure that the biases and predispositions of the interviewer do not interfere with a free exchange of information. - Used to explore issues and can collect some quantitative, but mostly qualitative data.

BA Skills

- Analytical Thinking and Problem Solving Skills - Business Knowledge - Communication Skills - Interaction Skills - Self Management - Software Knowledge - Software Skills

O-O Approach

- Application is a collection of interacting objects - Objects interact with people and each other - Objects send and respond to messages/methods

Structured Approach

- Application is a collection of processes organised into a system - Processes interact via flows of data - Processes accept inputs and produce outputs

Other elicitation techniques

- Apprenticing or Role Playing - Knowledge Acquisition techniques: -- protocol analysis and -- card sorting - Laddering - Document Analysis (analysing documents such as business plan, project charter, contracts, statement of work, emails, memos, etc) - Ethnography and Ethnomethodology - Goal Based Approaches - Scenarios - Viewpoints - Mixed techniques

Checklist (During the interview)

- Arrive on time and take responsibility for the agenda - Stick to the planned timetable, do not over-run - If you plan to tape the interview, ask the interviewees permission but take notes as well. - Probe for details by using different types of questions - Take thorough notes - Identify and document unanswered items or open questions

Guidelines for observation

- Ask enough questions to ensure that you have a complete understanding of the present system. - Document any procedures for handling exceptions - Consider each user who works with the system -- What information does that person receive from other people? -- What information does this person generate? -- How is this information communicated? -- How often do interruptions occur? -- How much down time occurs? -- How much support does the user require and who provides it?

Techniques (Requirements Elicitation)

- Brain Storming - Interviews - Requirements Workshops - Document Analysis - Observation - Prototyping - Survey questionnaires

Cardinality

- Business rule to indicate how many entities may participate in the given relationship between entities. - Way to specify the number of occurrences of one entity in a data model that are linked to a second entity. - Way to specify: -- How many times one instance of entity type can participate in *relationships* with the instances of another entity type. - *Numerical relation:* -- One department has many employees (1:M) -- One subject has one lecturer (1:1) -- Many tutors teach many subjects (M:N)

Business Process (Example)

- Buy goods online - Place an order - Withdraw money from an ATM - Apply for home loan, etc

Disadvantages of Interviews

- Can be *time consuming and costly* - Requires considerable commitment and involvement of the participants. - Interview *results have to be transcribed* and written and transcription and analysis of interview data can be complex and expensive. - Can be *subject to bias* - If conflicting information is given, it can be difficult to resolve and interviews are *not an ideal means of reaching consensus* across a group of stakeholders. - There is a risk of unintentionally leading the interviewee.

User Stories (Importance and Prioritisation)

- Common methods to prioritise (importance) each user story include: -- MoSCoW method (Must, Should, Could, Would/Won't) http://en.wikipedia.org/wiki/MoSCoW_method -- Weighted Shortest Job First (WSJF) http://agile102.blogspot.com.au/2013/01/weighted-shortest-job-first-bit-of-safe.html http://www.scaledagileframework.com/wsjf/ -- High, Medium, Low (HML) - (method used in this subject)

Different levels (Process Decomposition)

- Context level - First level - Second level

Disadvantages of Observation

- Could be very *time consuming* - Need to analyse *huge amounts of data* - Most people do not like to be observed and *may be disruptive* to the person being observed. - Requires trained and skilled observer to be most effective. - There may be *ethical problems* if the person being observed deals with sensitive private or personal data or directly with members of public. - There may be logistical problems if the staff being observed work shifts. - Unusual exceptions and critical situations that happen infrequently may not occur during the observation.

Disadvantages of Prototypes

- Depending on the complexity of the target system, using prototyping to elicit requirements can take *considerable time.* - A prototype may lead users to develop *unrealistic expectations* regarding the delivered system's performance, completion date, reliability and usability characteristics. This is because an elaborated, detailed prototype can look a lot like a functional system

Level 2 Diagram

- Detail/model all sub-processes and tasks within each process identified at Level 1. - Identify all the tasks from the start to end required to complete each Level 1 process and draw one separate diagram for each Level 1 process

Steps in an interview

- Determine the people/stakeholders to interview - Establish the objectives of the interview - Develop interview questions (topics of interview) - Prepare for the interview - Conduct the interview - Document the interview - Evaluate the interview

Relationship (Example)

- Each faculty offers many subjects - Each student enrols in many subjects

Disadvantages of Surveys

- Effective questionnaires are *hard to design* (e.g. leading questions, misinterpretation of questions). - Questions are usually *not answered completely* - The *response rates* for surveys *are often too low* for statistical significance. - There is no *automatic way of follow up* unless you do interviews later.

Open questions

- Encourage spontaneous and unstructured responses. - General questions establishing a viewpoint - Question that requires a full answer - Open-ended questions begin with the following words: why, how, what, describe, tell me about..., or what do you think about... - Examples of open-ended questions are: -- "What happened after I left?" -- "Why did Jim leave before Susan?" -- "Tell me about your day at work." -- "What do you think about the new season of this TV show?" -- "Is there anything else I should be asking you?" (Your last question of the interview)

Database Design

- Entity are implemented as relational tables -- For example, an Employee table. - Properties of Entities are implemented as columns (attributes) in the relational tables. -- For example, Employee Id, Name, Designation, etc. - Composite primary key of an associative entity is a primary key of a new relational table, primary key is also a foreign key here

Business Process

- Experts from IT and business engineering disciplines argue that successful systems deployment starts with the understanding of the ___________________ of an organisation. - It has a strong emphasis on how the work is done within an organization. - It is the combination of a set of activities within an enterprise with a structure describing their logical order and dependence, whose objective is to produce a desired result. - It is a collection of activities designed to produce a specific output for a particular customer. - It is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs

ERD vs Process Model

- Focus of ERDs is to *capture the important data* in the organisation, - the focus of Process Models is to *capture the business processes* in an organisation - ERDs focus on the *data to be stored and retrieved* in an efficient manner. It shows the *relationship* between the data. - a process model shows the business processes so that the processes can be analysed and improved.

Probes

- Follow up from a previous answer - "Why do you..." - "Where do you..." - "How often do you..."

Interview questions

- General -- What do you think of ... - Specific -- How many ... -- What do you do with... - Probes -- Why do you... - Most interviews use a combination of all three question types. The approach you take will depend on the type of interviewee

Present vs Future system

- Get a clear understanding of -- The overall objectives of the enterprise -- What do individual users of the system want to achieve in their job - Understand -- How the business is operating at present -- How people are working right now and what they cannot do with the existing system -- The problems with and inadequacies of the current system - Hence, discover the "new requirements" Many aspects of the current system will need to be carried forward into the new system, so it is important that information about what people are doing is gathered and documented. These are the requirements that are derived from the "current system". The motivation for the development of a new information system is usually problems with and inadequacies of the current system. So it is also essential to capture what it is that the users require of the new system that they cannot do with their existing system. These are "new requirements"

Workshop (requirements)

- Goal and Agenda -- Elicitation, Review, Sign Off workshops - Who...10-15 people max. - Location and time - Facilitator - Subscriber - Tools - Food - Ice breaker - Follow-up

Summary of Template

- Header: Everything before main flow - Main Flow: User actions and system responses - Footer: Everything after main flow - Alternatives: Alternate path to successful outcomes; successful but secondary paths. - Exceptions: Main flow fails. A list of things that could go wrong in the main flow, unsuccessful path

Requirements (Activities/Tasks)

- Identified -Captured - Managed - Communicated - Prioritised - Estimated - Scoped - De-scoped - Signed Off

Data Model

- Identifies the entities or objects that the organisation will need to hold data about. - identifies the data that must be captured, stored and retrieved. - describes the data in a logical (conceptual) manner. - creates a graphical representation of the entities, and the relationships between entities. - Focuses on what data is required and how it should be organised. - is a plan for building a database.

Steps for Drawing ERD

- Identify the *entities*/nouns in specification, requirements documents, interview transcripts, etc - Identify the *attributes* for each entity - Identify the *relationship* between entities -- Name with a verb such that the diagram reads in simple sentences - Identify *cardinality* for each relationship between entities as 1:1, 1:M, M:N, 0:1, 0:N - Identify *keys* (primary and foreign keys) for each entity -- Identify the attributes -The attributes(s) that uniquely identifies the entity -- Identify the composite primary keys, if any associative entities exist

M:N Relationships (Associative Entity)

- If you have (many to many) relationship you will need to create a new entity *called Associative Entity (ENROLMENT)* between the two entities that have this relationship - The new Associative entity (bridge entity) in most cases will have a *composite primary key*

Outcomes of BDP

- Improved processes (hence better performance of a business and increased competitiveness): future "To Be" processes - New processes (future To Be processes) - Value for customer - Reduced cost - Increased profit and competitiveness - Better staff morale - Customer retention

Observation

- In this approach, the analyst *observes* the actual execution of *existing processes* by the users (study a stakeholder's work environment), usually without direct interference. - Seeing the environment and domain where the system will be situated in action gives additional perspectives and a better understanding of system functionalities. - Observe system *as it actually behaves*. - Observation also allows us to *verify statements* made in interviews and surveys to determine whether the procedures within the domain really operate as they were described. - Through observation you might discover that neither the system documentation nor the interview statements are accurate. - Direct gathering of information rather than through description. - Be aware that individual behaviour maybe altered because they know they are being studied. - Avoid disturbing users from their normal activities. - Two types of Observations: -- Passive: You don't ask questions, simply observe and make notes. -- Active: You observe and have a dialog with the users/stakeholders while they are performing their work.

Included Use Case

- Includes' or 'Uses' -- Links a use case to another use case that describes common behavior (reuse). -- A base use case includes an included use case if an action step in the base use case calls out the included use cases' name -- The included use case describes a lower-level goal than the base use case -- Each of the included, more detailed use cases is a step that the actor or actors might have to perform to achieve the overall goal of the including use case. The arrow should point at the more detailed, included use case.

Elicitation requirements (Techniques)

- Interview - Questionnaires/Survey - Observation - Prototyping - Requirements Workshop

Techniques used

- Interviews - Surveys/Questionnaires - Requirements Workshops - Observation - Prototyping - Modelling: -- Stakeholders Modelling -- Process Modelling via BPMN 2.0 -- Data Modelling via ERD and Data Dictionary -- Object Oriented Modelling --- Use Case Diagram, Class Diagram, Sequence Diagram, State Transition Diagram, etc

ScrumMaster

- Is a Facilitator. - Represents management to the project. - Responsible for enacting Scrum values and practices. - Removes impediments. - Ensure that the team is fully functional and productive. - Enables close cooperation across all roles and functions. - Shields the team from external interferences.

Data Dictionary

- Is a centralized repository of information about data such as: -- Relationships to other data -- Origin -- Usage -- Format. - A file that defines the basic organization of a database. - It contains: -- A list of all files in the database -- The number of records in each file -- The names and types of each field. - Contains a *read-only* set of tables that provides information about the database.

UML (Unified Modeling Language)

- Is a standard language for specifying, visualizing, constructing, and documenting the artefacts of software systems - It is an Industry standard developed to support Object-Oriented analysis and design - It is a pictorial language used to make software blue prints. - It's diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system

Investigate the current system

- Is the existing system a manual one, based on paper documents, forms and files? - Is it already computerised? (a legacy system?) - Is it a combination of manual & computerised? - If it has evolved over the years, what sections are still usable and what sections do not meet the needs of users? - Answering these questions leads to defining the boundary of the new system and its interface to the existing system

Situation for observation

- It can *verify or disprove assertions* made by interviewees/stakeholders. - It is *useful in situations where different interviewees have provided conflicting information* about the way existing system works. - Observation is essential for gathering some quantitative and mostly qualitative data about people's jobs

Epic

- It feature is a large user story. It is a big, sketchy, coarse-grained story. - Because it is generally too large for an agile team to complete in one iteration, it is split into multiple smaller user stories before it is worked on. - It will later be decomposed into smaller stories that fit more readily into a single iteration. This is done in the Backlog Refinement Meeting. Watch "Backlog Refinement Meeting" video on UTS Online

Context diagram (SCD)

- It is a diagram that defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it. - A _______ ________ allows a team or an individual to produce a high-level model of an existing or planned system that defines the boundary of the system of interest and its interactions with the critical elements in its environment. - It shows (parts/components): -- The system that is being analysed. -- The entities (other systems, people and organisations) that interact with the system. -- The information/data (not the processes) that flows between the system and each entity.

Entity Relationship Diagram

- It is a graphical representation of the data requirements for a database. - The Entity-Relationship Model is a conceptual data model that views the real world as consisting of entities and relationships. - It is a graphical representation of the entities relevant to a chosen problem domain, the relationships between them, and their attributes - Describe data requirements of the business - Represent the business rules that apply to an organizations data - Confirm business and data requirements and provide direction to the architecture and design team as they move forward with database design

BPMN (Business Process Modelling Notation)

- It is the standard notation used for business process modeling. - The primary objective of developing ________ is to provide a *notation that is readily understandable by all* business users, from the analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. - It defines a Business Process Diagram (BPD), which is based on a flowcharting technique tailored for creating *graphical models of business process operations*. - A Business Process Model, is therefore, a network of graphical objects, which are activities (i.e., work) and the flow controls that define their order of performance.

User Story (purpose)

- It serves as placeholders for conversations about the users' detailed needs. It is a starting point of *conversation and confirmation* between the analyst and stakeholders (e.g. product owner or process owner). - Based on the User Story, you have further conversations with the user or proxy user and identify the additional details. The Product Owner has further conversations with developers. - Is planned for project releases and iterations - Is written on a *story card, index cards or sticky notes* stored in a shoe box, and arranged on walls or tables to *facilitate planning* (releases and iterations) and discussion - they strongly shift the focus from *writing about features to discussing them*. These *discussions are more important* than whatever text is written in user stories.

Composite Primary Key

- Mainly used for M:N (many to many) relations - A composite primary key uniquely identifies Student Subject attributes - Student Subject Relationship (is *called "Enrolment" - Associative Entity)* -- Student ID (part of Composite Primary Key) -- Subject ID (part of Composite Primary key) -- Semester -- Mark -- Grade

ERD (Example)

- Network structure - Entities are located at the nodes of the network - Connections between the nodes define the relationships and cardinality

Interview (DONTS)

- Never show aggression nor create an impression of apportioning blame. -- "I've been told there are some major issues in this area and it's my job to fix them" -- "Conducting a study to identify how we can provide you with better support for your work..." - Do not force solutions on users- play role of an advisor and facilitator - Explain limitations of the system in user terms - Describe how system will help users in their work - Do not ask leading questions, ask for suggestions for improvement and follow them up -- Not many yes no questions - they are usually leading questions

Workshop Guidelines

- Participants must be selected carefully representing different classes of stakeholders. - Ensure that all stakeholders participate and have their input heard. - Must have a skilled facilitator (you as a BA). - You should remain neutral and promote discussion. - Meeting room should have all the necessary facilities and the environment be conducive to hold effective meetings - Need visual aids (e.g. flip charts, whiteboard, large screens, GUI)

Interview guidelines

- Plan and organize - Start with high level general questions - Ask specific questions - Seek lead for more information from stakeholders - Keep it to 1-2 hours - Take and share meeting notes and minutes - Record following up and action items - Focus on "Project" and not the people - Ask, listen, probe, understand and record (ALPUR) - Avoid blaming, jargons, forcing your opinion

Requirements Elicitation (Requirements Process Stages)

- Process of seeking, uncovering, acquiring, and elaborating requirements for computer-based systems. - Requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements to the elicitation process. - A complex process involving many activities with a variety of available techniques, approaches, and tools. - *Stakeholders Analysis*

Closed questions

- Question that can be answered by single word (yes or no) or a short phrase. - They are used to obtain facts and specific pieces of information. - Limit or restrict the response requiring specific answer such as a number, explanation of a report, reason for an action" - Examples of closed-ended questions are: -- "Who will you choose?" -- "What brand of car do you own?" -- "Did you speak to Bob?" -- "Did Susan leave with Jim?"

Requirements Quality

- Requirements are *SMART* -- Specific, Simple -- Measureable, Manageable -- Attainable (Achievable, Actionable, Appropriate) -- Realistic (Rationale, Result Oriented, Realistic to deliver) -- Time-bound (Timely, Testable, Traceable)

Disadvantages of Workshops

- Risk involved in speeding up the decisions. Sometimes the decisions made about the requirements are not optimal. - May suffer from *dominance and submission.* - At times, details are inappropriately defined or missed altogether.

Requirements Engineering

- Software system development is driven by - refers to the process of defining, documenting and maintaining requirements and to the subfields of systems engineering and software engineering concerned with this process

Stakeholders (Classes/Types/Roles)

- Sponsor - Owner - Project Manager - Business Analyst (BA) - our role - Quality Analyst - Customer - Supplier - End User - Domain Subject Matter Expert (SME) - Implementation Subject Matter Expert (SME) - Support Professionals - Regulator

Understand Conflicts

- Stakeholders may have differing or conflicting requirements - Not understanding stakeholder differences can lead to -- Poor communication -- Miscommunication -- Conflicts and failed software projects - Unless there is understanding of what causes the conflicts, it is very difficult to determine appropriate trade-offs - *Facilitate communication* between the stakeholders who are in conflict over the requirement in order to resolve the issue. - Conflicts may be resolved through *formal meetings* among affected stakeholders, through research, resolution by a third party, or other methods as appropriate

Checklist (After the interview)

- Thank interviewees for their time. Offer to provide them with a copy of your notes for them to validate. Make an appointment for further interviews if needed. - Review and transcribe your tapes or notes ASAP after the interview while the content is still fresh in your mind. - Review your notes for accuracy, completeness, consistency and understanding. - Transfer information to appropriate models and documents. - Identify areas needing further clarification. - Send interviewees your notes and update your notes to reflect their comments.

Simple Level 1 BDP

- The above diagram contains no Start and End events as it has independent business processes and each of these processes will be detailed in the following Level 2 diagrams which will have the start and end events. - Notice that there are no Sequence/Message Flow arrows between these processes as these processes are independent. In a number of Level 1 diagrams (for example in your workshop case study processes), you will see sequence flow arrows associating the various level 1 processes as those processes maybe be associated to each other (but not in the above example). - So, the sequence flow arrows in Level 1 diagrams should only be shown if the processes are associated with each other

Iterative and incremental development

- The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. - Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. - Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through cross-discipline work, from the requirements to the deployment.

Relationship (Use case)

- The connection between and among the actors and the use cases. Links an Actor to a Use Case - There are several types of relationships that may appear on a use case diagram: -- *An association between an actor and a use case* - *An association between two use cases (includes and extends)* - *A generalization between two actors* - *A generalization between two use cases* - *Associations* are depicted as lines connecting two modeling elements with an optional open-headed arrowhead on one end of the line indicating the direction of the initial invocation of the relationship. - *Generalizations* are depicted as a close-headed arrow with the arrow pointing towards the more general modeling element.

Requirements Specification

- Traditional approach using IEEE template -- Upfront and detailed -- Simple plain language requirements statements -- Structured use cases (next week's lecture) - Agile approach (used in this subject) -- Iterative -- User stories: card, conversation, confirmation -- User story map -- User story estimation and prioritisation -- User story or agile card wall

The Team

- Typically 5-9 people - Cross-functional: -- Programmers, testers, user experience designers, etc. - The development team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each sprint (the sprint goal). - Teams are self-organizing -- Ideally, no titles but rarely a possibility - Membership should change only between sprints

Use Case Diagram (Relationships)

- Unbroken line -- Communicates - Dotted line with arrow -- Includes - Straight line with arrow -- Generalizes -Dotted line with arrow and text -- Extends

Objectives of BDP

- Understand the current business processes - Understand how the work is done in an organisation - Clarify responsibilities - Identify process inefficiencies (problems with current processes) - Support continuous process improvement - Support process management - Support process development - Support process execution

What do we want from users?

- Understand their problems - what is limiting them? - Understand the requirements of the current and future system - Understand the scope - Understand the requirements priority

Elicitation Process

- Understanding the application domain & the properties of the existing system - Identifying the sources of requirements - Identifying and analyzing all the relevant stakeholders (we did this last week) - Selecting the approaches, techniques and tools for elicitation - Eliciting the requirements from the stakeholders and other sources using the selected techniques, approaches and tools

User Story

- User stories are short, simple description of a *feature* told from the perspective of the person who desires the new capability, usually a user or customer of the system. - User stories are short descriptions of *functionality-told from the perspective of a user*-that are valuable to either a user of the software or the customer of the software.

Conflicts and Challenges

- Why are there conflicts? -- Empires, power and fear - Why are there differences between stakeholders? -- Different views, time-frames, granularity, experiences - What influences these differences? -- Communication, Openness A conflict may result from stakeholders in different areas *viewing requirements from different perspectives*. It may also result from *conflicting priorities*. Facilitate communication between the stakeholders who are in conflict over the requirement in order to resolve the issue. Conflicts may be resolved through formal meetings among affected stakeholders, through research, resolution by a third party, or other methods as appropriate. Conflicts that affect the requirements must be resolved before formal approval is given to those requirements. Source: BABOK guide

Difference between User story and Use Cases

- With so many engineering teams making the paradigm shift from waterfall to Agile Software Development, people often get caught up in having a pure Agile process which would include the use of User Stories. So what's all of the hoopla with User Stories? What are they, how are they different from use cases, do I need them, and where do they fit in the process? - *What is a User Story?* Simply put, written from the context of the user as a simple statement about their feature need. - *How is a User Story different than a Use Case?* While a use case is highly structured and tells a story, the User Story sets the stage by stating the need. A User Story is the prelude to the use case by stating the need before the use case describes the need in detail. - *How does the User Story fit into the process?* User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized. The User Stories will then morph themselves into the business requirements and use cases. - Can I use Use Cases in agile development? Yes, but keep the use cases lean with less features so that they can be iterated and adapted with each release. - *Purpose*: The purpose of the use case is to document an agreement between the customer and the development team. User stories, on the other hand, are written to facilitate release and iteration planning, and to serve as placeholders for conversations about the users' detailed needs. - *Scope*: Both are sized to deliver business value, but stories are kept smaller in scope because we place constraints on their size (such as "no story can be expected to take more than 10 days of development work") so that they can be used in scheduling work. A use case almost always covers a much larger scope than a story. - *Completeness*: The text on a story card plus acceptance tests "are basically the same thing as a use case." This means that the story corresponds to the use case's main success scenario, and that the story's tests correspond to the extensions of the use case. - *Longevity*: Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. User stories, on the other hand, are not intended to outlive the iteration in which they're added to the software. While it's possible to archive story cards, many teams simply rip them up.

User Story (Guidelines)

- Write your stories so that they are easy to understand. - Keep them simple and concise. Avoid using multiple sentences in each user story (one sentence only). - Avoid using conjunctions such as 'and', 'or', 'but', etc. Also avoid using limiting phrases such as 'unless', 'except', 'without', etc. Avoid confusing and ambiguous terms, and use active voice. - Keep user stories short and simple with one functionality only. - User stories should be clear, feasible, and testable and comfortably fit into a sprint. - User stories should have *acceptance criteria*. Acceptance criteria for a user story allow analyst to describe the conditions that have to be fulfilled so that the story is done/completed. The criteria enrich the story, they make it testable, and they ensure that the story can be demoed or released to the users and other stakeholders

Types of questions (Surveys/Questionnaires)

- Yes/No questions: e.g. "Do you print reports from existing system?" Yes No (please circle one) - Multiple Choice questions: e.g. How many clients do you obtain in a year? a) 1-10 b) 11-20 c) 21-30 d) 31 + - Scaled Questions: e.g. How satisfied are you with the response time of the stock update? (please circle one option) 1. Very satisfied 2. Satisfied 3. Dissatisfied - Open-ended questions e.g. What additional reports would you require from the system?

Requirement

- a condition or capability needed by a stakeholder to solve a business problem or achieve an objective (BABOK V2.0) OR - a statement of need that must be met by a particular product or service to solve a business problem or achieve an objective (Robertson & Robertson 2012) = People + Process + Data + Software System + Quality + Assumption + ...

Requirements examples

- a customer must be able to place an order for a book on the phone in less than 5 minutes between 9:00 AM and 5:00 PM (Monday to Friday) or/and - a customer must be able to place an order for a book via a 24/7 online system in less than 3 minutes

Primary Key (Entity Key)

- an attribute or group of attributes that *uniquely identifies an instance of an entity.* -- Student Id is a primary key since it identifies an individual Student instance. -- An Employee Id is a primary key for the Employee entity as it uniquely identifies each employee - must be unique -- absolutely no duplicates -- Very often are numeric -- have to be created to be unique

Foreign Key (Entity Keys)

- are attributes that are used to identify an instance of another Entity Type. - When a Primary Key of one entity is used in another Record/Table, it is referred to as a 'Foreign Key'. -- For eg the primary key Department Id being used in Employee table - Employee record/table -- Employee Id (Primary key) -- Name -- Address -- Drivers licence -- Tax File Number -- *Department Id (Foreign key)* - Department record/table -- Department Id (Primary key) -- Department Name -- Location

Entity Keys

- are the basis of the relationship between entities - is a logical (and physical) pointer - is used to identify another entity that the current one wishes to be associated with

Requirement (why?)

- developing a new or altering an existing business process, service or product e.g., order management process - developing a new or altering an existing software system e.g., online order processing system

User Story (Estimation and Priortisation)

- estimated in terms of time taken to complete/implement a user story by the development team. - prioritised (importance) to be included in a certain release (which user stories should be included in each release)

Modelling

- is a representation of a real world entity or object or subject of interest (TOGAF 9.1) e.g., business process model, data model, software system model - AS IS (Current State) and TO BE (Future State) Models

Data Models

- model people, things, places and concepts about whom data is required - identifies the entities or objects that the organisation will need to hold data about

Requirements Process

- stages/phases (e.g. Planning, Analysis, Elicitation, Specification, etc.) - activities and tasks (within each stage/phase) - techniques - tools for discovering the purpose of the "software", and the needs of the users to support their activities - identifying stakeholders - Identifying their needs - documenting these needs/requirements in the form of a *model* that is amenable to -- analysis -- communication -- subsequent implementation (creating software)

Requirements Management (Requirements Process Stages)

- the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders - It is a *continuous process* throughout a project. The purpose of requirements management is to ensure that an organization documents, verifies, and meets the needs and expectations of its customers and internal or external stakeholders

Object Oriented Models (OO Models)

- using Unified Modelling Language (UML) - Examples: -- Use Case Diagram -- Class Diagram -- Sequence Diagram -- State and Event Diagrams, etc

Checklist (Before the interview)

-- Establish the objective for the interview -- Determine relevant users to be involved -- Determine project team members to participate -- Build a list of questions and issues to be discussed -- Review related documents and materials -- Set the time and location -- Inform all participants of objective, time and location

User Story Map

1. Capture PR | 2. Get Quote | 3. Review Quote | 4. Place Holder Each column contains user stories, organised by priority

Level 2 BDP

A Level 2 business process diagram (based on BPMN) breaks down a level 1 process like "Request Loan" into its sub-processes, as seen below. - Level 2 means a greater level of detail than Level 1. It can include lanes, pools, gateways and data objects

Requirements Specification (Requirements Process Stages)

After analysing and modelling the requirements, requirements are specified and documented in a software *requirements specification* (SRS) document

Actor (Use case)

An actor is a person, organization, or external system that plays a role in one or more interactions with your system

Use case study

Contains *4* components: - *System boundary*, which defines the system of interest (scope) in relation to the world around it. - *Actors*, could be a person, organization, or external system that plays a role in one or more interactions with your system. - *Use cases*, is a generalized description of a set of interactions between the system and one or more actors. The system functionalities are captured in use cases. - *Relationships* between and among the actors and the use cases

Page

Data Object - Considered artifacts - do not have any direct affect on the sequence flow or message flow - Provide information about what activities require to perform

Diamond

Gateway - Used to control the divergence and convergence of sequence flow - Determines branching, forking, merging and joining - Internal markers indicate the type of behavior control

Structured Analysis Focus

Identifying and Modelling: - Processes (BPMN) -- Actions and transformations - Data (ERDP) -- Consumed and produced by the system

Business Requirements Modelling

Involves understanding the client's business problems and needs (requirements), and developing a set of diagrams known as requirements models, each of which focuses on a different aspect of the users' needs (business needs). e.g. - People or Stakeholders (Modelling) - Process (Modelling) - Data (Modelling) - Object Oriented Modelling

Why have a context diagram

It can: - help define and agree the *scope or boundary of the system* of interest - provide a simple *high-level picture or birds eye view of the system* of interest. - *Help identify the elements in the environment of the system* of interest that it interacts with. All systems operate in an environment; failure to pay attention to that environment will lead to failure. - Identify and define the external interfaces the System of Interest logically has to have with the outside world. - The interfaces between the system and the external entities are shown with labeled arrows. The context diagram *depicts the project scope at a high level of abstraction* but reveals nothing about the system functionality, architecture, or look-and-feel. Nor does it explicitly identify the features or functionality that are in or out of scope. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities.

Double column table

Lane - Sub-partition within a pool - Extended the entire length of the Pool - Organizes and categorizes activities

Scrum Framework

Roles: - Product Owner - ScrumMaster - Team Ceremonies: - Sprint Planning - Sprint Review - Sprint Retrospective - Daily scrum meeting Artifacts: - Product backlog - Sprint Backlog - Burndown charts

Solid arrow

Sequence Flow - Used to show the order of activities

Text

Text annotation

System Boundary (Use case)

The rectangle around the use cases is called the system boundary, it indicates the scope of your system - the use cases inside the rectangle represent the functionality that you intend to implement.

Attainable

also referred to as achievable, actionable, or appropriate. All are fine attributes and are intended to ensure that the requirement is physically able to be achieved given existing circumstances

Scrum (Agile)

an iterative and incremental agile software development framework for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.

Project Manager (Stakeholder Classes

are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project's objectives are met while balancing the project constraints, including scope, budget, schedule, resources, quality, risk, and others

Developers/Software Engineers (Stakeholder Classes)

are responsible for the construction of software applications. Areas of expertise among developers or software engineers include particular languages or application components.

Requirements Analysis (Requirements Process Stages)

determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.

Sponsor (Stakeholder Classes)

is an owner representative and represents owner's interest. Pays for the development of the product. For e.g., Departmental Manager, Program Manager, etc

Business Process Modelling

systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed or improved - Conceptual modelling of business processes is performed: -- to facilitate the development of software that supports the business processes, and - It is used to map out an organization's current (or "as-is") processes to create a baseline for process improvements and to design future (or "to-be") processes with those improvements incorporated. - Modelling of a business process typically shows events, actions and links or connection points, in a logical order from end to end

Process (modelling)

the analytical representation or illustration of an organization's business processes It is used to map out an organization's current (or "as-is") processes to create a baseline for process improvements and to design future (or "to-be") processes Example: Purchase books ~ Place order -> Receive Order -> Make Payment

Time Bound

where appropriate each requirement should be time-bound or specify by when or how fast a requirement needs to be completed or executed. Also whether a requirement is traceable?

Structured Interview

where the interviewer has a *pre-defined set of questions* and is looking for answers.

Unstructured Interview

where, without any pre-defined questions, the interviewer and the interviewee *discuss topics of interest* in an open-ended way.

Associative Entity and Composite Keys

|Person| *Person-ID* - Name, Address 1 | M| <Works For> *Person-ID* *Project-ID* - Time Spent M| 1 | |Project| *Project-ID* - Start-Date, Budget *Bold* is Composite Primary Key Normal are Attributes - In |blah| Specific to entity - in <blah>, Specific to relationship