Interested or involved bodies in the development of a software system
A stakeholder's need that must be fufilled to reach the system's objective, for instance, a train system has the requirement of a train that stops at Minchinbury and arrives at Burwood between 5 and 5:30.
Abstract ideas of stakeholders, systems, and business processes used to emulate their requirements, attributes and problems for decision making
practice of enabling change in an enterprise by identifying requirements and reccomending a solution
Process of obtaining specific requirements (like business rules) for the ] process the client has ordered
The steps needed for software development
Discovery of new requirements as the process is on-going, this is why agile methods are preferred.
Reviewing the clarity and integrity of current requirements
Obtaining requirements by discussing with stakeholders through an interview. Biases between interviewee must be put aside, interviews can be structured (pre-planned questions) or unstructured ()
Questions inciting detailed and descriptive responses
Questions inciting a short response with a definitive answer
Asking for more general answers when interviewee is reluctant
+ Allows for full discussions and greater detail
+ Allows for private opinions to flow
- Time consuming and costly
- Subjection to bias
- Results need to be transcribed
List of questions given to stakeholders to take individually. Can ask:
- Yes/no question
- Multiple choice
- Scaled question, where the stakeholder offers a rating
- Open-ended question, that incites detail from the stakeholder
- Yes/no questions,
- Multiple choice questions,
- Scaled questions,
- Open questions,
Studying the stakeholders using the current system, may be passive or active
+ Data collected in real time
+ Can be used to verify notes
- Time consuming
- May be disruptive
- Lots of data to analyse
Working model that imitates the final model, used to test and verify interface, requirements being met and output with stakeholders
Images representing the look and flow of the interface, used to validate ideas
+ Allows for early feedback
+ Inexpensive to fix prototype
- May be time consuming
- May cause unrealistic expectations for the system
Workshop that does all of the above, used to update and gain requirements on system
+ Collaboration between stakeholders
+ Generates product ideas
- Risk of rushing decisions
Combining the activities of an enterprise with structure and logical order from start to end, that is, the activities a business undertakes for the benefit of its client
Representing business processes for analysis and amelioration, done to make software development for the system easier
Dividing entities of a business into smaller, related parts, to make it easier to understand business processes
System Context Diagram; diagram defining relationship between system and its environmental entities (like context diagram in IPT). This diagram shows:
- The system in question
- The interracting entities
- Information and data being exchanged between system and entitites
\
They help show the scope of a system, and the environment interracting with it.
- Identify all business processes
- Model all subprocesses of the level 1 business processes
- Identify all tasksa from start to end needed to complete each level 1 process
Notation in business process diagrams (data flow diagrams in IPT):
- Event, event that has cause and effect represented by circles
- Activity, work that business performs represented by rectangles
- Gateway, controls conditional flow, whether two events or activities can occur on different circumstances represented by a diamond
- Sequence flow, arrow showing order of activities in a process represented by an arrow
- Message flow, shows flow of messages between two participants
- Association
- Pool, represents a participant in the system represented by a rectangular environment around the entire diagram
- Lane, partition of pool used to categorise different events
- Data object, databases and such represented by a generic page file image
- Group
- Text annotations
Model that identifies entities and data, describes nature of the system's data, demonstrates entity relationships, and is the foundation of a database plan
Entity Relationship Diagram; Data model that demonstrates entities and relationships. They demonstrate business rules and describe the data requirements of a business
Normal; Person, Place, Thing, idea, etc.
Associative; Many to many relationship connector
Weak; Normal entity reliant on another entity to exist (makes part of PK)
Data field in an entity
Identifier for an entity, can be:
Primary Key; ID that represents its own entity
Foreign key; ID of an entity in another entity
Composite Key; Use of many fields to make one ID
Identifier for an entity, can be:
Primary Key; ID that represents its own entity
Foreign key; ID of an entity in another entity
Composite Key; Use of many fields to make one ID
Identifier for an entity, can be:
Primary Key; ID that represents its own entity
Foreign key; ID of an entity in another entity
Composite Key; Use of many fields to make one ID
Identifier for an entity, can be:
Primary Key; ID that represents its own entity
Foreign key; ID of an entity in another entity
Composite Key; Use of many fields to make one ID
Table that describes the attributes of an entity (data type, character size, description, attribute name, etc)
Software Requirements Specification; Document listing the system service and capabilities in detail, defining the functional requirements for software developers, often used as a contract to validate what the stakeholders want
SRS document format enforced by the IEEE, the head of technology standards (including WiFi). It's detailed, has simple language, and has structured use cases
SRS document format enforced by this subject. It is incremental (things canm be added onto it),
The values of agile software development:
Process including an acting "product owner" (representor of stakeholders) and a Scrum master (someone who conducts a short daily discussion on how today's work fits with the stakeholder requirements). The product owner creates a product backlog (requirements yet to implemet into the system), and the sprint backlog is created by scrum master and the scrum team to log the current status on how the development is going for each sprint (a sprinty is a day of developing the system)
List of desired functions of a system by a product owner, explained using user stories
Team members sign up to work on parts of the requirements and log their completion
Functionality requirements told from the perspective of an end user, often used in agile projects. It is not an entire requirement, as it needs to be thoroughly discussed with the stakeholder in question. Should avoid conjunctions, simple, and specific. User stories are given a time frame to be programmed, and priority.
Test to confirm that a user story accurately describes the conditions of a user story
A big user story
Offering a score from 1 to 10 on a user story to describe effort to put in practice
Unified Modelling Language; language used to visualise, construct, and document artefacts of a system, OO support added in version 2, UML diagrams are useful for programmers, stakeholders, and anyone interested in the system structure
Diagram with system users (actors) and a system environment drawn as a rectangle with processes actors may request (use cases) as ovals embedded, and relationships between the users and system processes are demonstrated with lines. User stories can make many user cases, and vice versa
Line connecting two modelling elements that can optionally have an arrow head to indicate direction
Line with closed arrow head pointing to the more general element
Narrative demonstrating what the system should do to respond to an event, capturing actor messages
Static diagram describing the structure of a system through the system's classes, attributes, operations (methods) and relationships between classes and objects. Used for modelling to be translated into programmed code. Used to visualise, describe and document system as well as help construct code.
Definition of objects with shared attributes and methods, used as a blueprint to create said objects. Objects are instances of classes
Properties describing state of the class
Properties describing behaviour of the class
Association between classes
Numerical relationship between two classes
UML diagram that shows how objects interact with messages, demonstrating how objects collaborate with one another for their behaviours. They are used when viewing the behaviour of several objects with one use case (called object level). There are two types of these diagrams:
Visual representation of a use case, capturing the behaviour of the use case. Objects are shown as a "lifeline box" in the use case diagram. Sequence diagrams show messages between classes or objects overtime in a sequence.
Tools used in sequence diagrams used to display loops and conditional switches, can have the following opeators that contain a label (operator name) and guard (looping or switching condition):
Instances of classes with data, methods and properties defined by a class. Objects may have different state, such as changing variables
Diagram showing changing state of one object over a time period, helping analysts understand system behaviour. It also helps estimate an objects lifespan, understand the types of values objects take, and so forth
Changing state, this occurs due to events that may or may not be related to time (such as a button being pushed, a time interval being reached, and so forth)