CSSE3002 Lecture Notes - Lecture 2: Opportunity Cost, Brainstorming, Business Model Canvas
28 Jun 2018
School
Department
Course
Professor
Requirements engineering
-Figuring out what people want
-Term for everything we do relating to understanding and managing requirements –
requirements gathering/analysing/validating
-Requirements always change
-Users, developers have to understand the requirements – validate the requirements
– could use prototype – get feedbacks from prototype
-Software requirements: what does the software needs to do
-System requirements: in an assumption that this is in a larger overall system, e.g.
has manual procedures, hardware, interaction between software and hardware etc
What is a requirement?
-A condition that needs to be met by a system or component to meet some imposed
constraint or requirement – requirement is also a documentation of these things
-Products: results of doing the process – the intent is to get an agreement between
the client and developers – and to understand/agreeing what was wanted – finding
basis for further development
Waterfall-specified features
-Half of the specified requirements were never used (too complex, redundant, not
needed) – want to find a process to cut down the left side of the pie, i.e. process that
caters for changing requirements so that only needed requirements are delivered
Cost to fix faults
-Easy to fix when fault is discovered during requirements
-Faults discovered during design stage – Interaction/already delivered
parts/dependencies – take more time and effort
-Function point – functional size of software vs lines of code – standardised approach
to measuring software
-Requirements is where problems tend to occur and is the stage where it is the
easiest to resolve these problems
Why is RE important?
-A more rigorous approach to capture and manage requirements
-Typically, client only have a general idea of what they want – need a process for
them to tell us what they want – keep them engaged because their wants and needs
might change over time – tell us the changes as we progress through the
development
Consequences if requirements wrong
-Deliver something that’s not what people want – not used
find more resources at oneclass.com
find more resources at oneclass.com
-If requirements are contradictory – end up with corrupted data or crashes in the
system – higher cost maintaining the software
Benefits of good requirements
-Acceptance criteria – so that developers get paid, customers tell what they want
-Good understanding of what customers want, able to estimate the cost at the
beginning – although requirements will change, if the customer is known/regular in
the industry, able to estimate how much it will change
-Complete a requirements document that is suitable for the project – keep it up to date
as the project progresses – two different types (user stories, use cases)
Functional requirements
-Does something – functionally useful
-When users talk about requirements it is usually functional requirements
Non-functional requirements
-Does not relate directly to the functionality – relate to the constraint required for the
system
-Product properties – e.g. credit card details maintained in a secure fashion, system
processes X number of transaction per second
-Process properties – constraints of the way you conduct the project e.g. conform to a
standard (set of rules of how you will build the software e.g. railway safety standards)
-Also has to be testable/measurable
-ISO Standard for NFR
oSafety requirements: safety concerns
oInterface requirements: describe how the system is to interface with its
environment, users and other systems. E.g., user interfaces and their
qualities (e.g., user-friendliness)
oHuman engineering requirements: usability/interface design/ease of use
oQualification requirements: A qualification requirement is a skill level, license,
or certificate that is needed for a work order task or an assignment.
oPerformance requirements: describe performance constraints involving
time/space bounds, such as workloads, response time, throughput
and available storage space. E.g., “system must handle 100
transactions/second”
reliability involving the availability of components and integrity of
information maintained and supplied to the system. E.g., “system must
have less than 1hr downtime/3 months”
security, such as permissible information flows
survivability, such as system endurance under file, natural catastrophe
find more resources at oneclass.com
find more resources at oneclass.com
Document Summary
Term for everything we do relating to understanding and managing requirements requirements gathering/analysing/validating. Users, developers have to understand the requirements validate the requirements. Could use prototype get feedbacks from prototype. Software requirements: what does the software needs to do. System requirements: in an assumption that this is in a larger overall system, e. g. has manual procedures, hardware, interaction between software and hardware etc. A condition that needs to be met by a system or component to meet some imposed constraint or requirement requirement is also a documentation of these things. Products: results of doing the process the intent is to get an agreement between the client and developers and to understand/agreeing what was wanted finding basis for further development. Easy to fix when fault is discovered during requirements. Faults discovered during design stage interaction/already delivered parts/dependencies take more time and effort. Function point functional size of software vs lines of code standardised approach to measuring software.
