CSSE3002 Lecture Notes - Lecture 3: Devops, Continuous Delivery, Version Control
28 Jun 2018
School
Department
Course
Professor
Requirements Modelling
-Gain understanding
-Figuring out details of a situation
-An approach to SE to model-driven engineering, create a model of what people want, then
create a model of how to implement it, then generate a system for the model. Analyse the
model, then make arguments about the model and develop tests to test system – a company
went with this approach, and they claim that 90% of the code is produced automatically, 4%
written by hand
-Produce model to understand things, produce system from model
-Understand what we are going to do – project management models
-For communication – describe it to people (for developers/stakeholders/public)
What is a model
-Abstraction of reality
-Ignore trivial details - Different models for different audience
-Complex system – large & complex – hard to understand – models able to manage
complexity – able to partition a model into parts – focus on details one part at a time
Requirements models
-A lot of types of models
oEnterprise models: business process models – describe the enterprise and how it
operates
oGoals: high level descriptions of what to achieve with the goals
oAgents: things that have some responsibility with a process (human/automated) –
provide service/interface
oRoles: detailed view of the types of users (ways people use the system)
oInformation: describe the data
oBehaviour: describe functionality
oTime: know timing constraints
oQuality: expectation of system (NFR)
Purpose
-Able to guide elicitation process – analyse the model – able to identify which parts
unclear/incomplete/imprecise
-Identify inconsistency – model describes features: able to resolve the inconsistency (why?
different stakeholders propose different req., don’t understand detail)
-Check understanding – complete? Unambiguous? Visualise aspects of the system
Limitations
-Never have all the details of the problem in the model (model simplify reality)
find more resources at oneclass.com
find more resources at oneclass.com
-People might make mistakes (leaving things out)
Modeling languages
-Natural language
oUseful because it is expressive but it is ambiguous
-Semi-formal
oStructure and a set of semantics around the language, eliminate a lot of ambiguity
oBut the cost is less flexibility because there are rules to abide by
oBecause there are semantics – able to do reasoning – analyse the model
-Formal
oPrecise meanings, precise rules – reasoning can be done more extensively than the
semi-formal language
oBut it requires a lot of details needed to capture the information needed
oUsually expensive, hence typically only a certain part of the system is modelled with
formal language, other parts semi-formal
Desired characteristics
-Implementation independent: describe what is wanted without describing the method to
achieve it (technical details)
-Abstract – capture general notion without repeating details
-Formal – some level of formality which is appropriate to the problem
-Constructible – tackle it in a modular process – different people work on different parts of the
model (able to construct a larger model from existing models)
-Analysable – able to analyse – is it consistent? Complete? Valid?
-Traceable – ability to check if the design model corresponds to the requirements model,
implementation corresponds to the design model etc
-Minimal – not an overwhelming burden to learn, understand and use – as simple as possible
for the problems
Requirements modelling techniques
User stories
Stakeholders
-People interested in outcomes/how project is conducted
oProject sponsor (scrum: product owner): describes what the system should do and
pays for it, subordinates: to work with, describes things to happen in a certain
way(more technical)
oEnd-users: people who use the system
find more resources at oneclass.com
find more resources at oneclass.com
oInterested parties: other people in the organisation who have interest in the results of
the projects (not using/paying), but will be affected because might interact with end-
users
oRelated project teams: system might need to work with other systems, either existed
or is in the process of building, hence need to interact the building teams to maintain
the interfaces between these systems to ensure that it works properly with everything
else.
-Interested in the way the project is conducted
oProcess improvement team: only happens in large companies, works with
development team to figure out ways of how to work better – improve software
engineering process – not worrying about delivering the product – hence able to see
problems and make suggestions to solve the problems
oQA team: quality assurance team: happens in medium to large companies, interested
in delivering quality products – also try to improve process which aims to deliver
higher quality products
Scope
-What needs to be done? What shouldn’t be done?
-How much money the project sponsors are willing to spend for the system?
-How much developers can realistically do?
-E.g. have a grand vision, but want to deliver in 3 months – work on important features now for
the next 3 months, others can be completed later
-Work out what’s going to be in scope and out of scope – values stated in BMC – but don’t
have enough resources and budget for everything – decide which values are possible to be
delivered, others will be out of scope – create requirements model from the values that are
set possible to deliver
Story Identification Activities
-Start by identifying the stories
-Developer, customers, etc sit down and write user stories
-ideal set of people: small group – one customer representative of one type of customer/user,
business analyst, a few developers, tester – mixed team
-write down what this type of user wants to achieve in the system
-Each story is a description of one thing the system should do – in user’s perspective
-Tester is required because need to know how to check to see if developers are able to deliver
what the customers want
-Not just describing the requirement, also the acceptance criteria (i.e. what has to be done with
the story, what has to be done to test if the story is implemented correctly)
-One sentence description of a functionality – small, should be able to build it in a few days
-Focuses on functional requirements
find more resources at oneclass.com
find more resources at oneclass.com
Document Summary
An approach to se to model-driven engineering, create a model of what people want, then create a model of how to implement it, then generate a system for the model. Analyse the model, then make arguments about the model and develop tests to test system a company went with this approach, and they claim that 90% of the code is produced automatically, 4% written by hand. Produce model to understand things, produce system from model. Understand what we are going to do project management models. For communication describe it to people (for developers/stakeholders/public) Ignore trivial details - different models for different audience. Complex system large & complex hard to understand models able to manage complexity able to partition a model into parts focus on details one part at a time. Able to guide elicitation process analyse the model able to identify which parts unclear/incomplete/imprecise.
