Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Requirements Analysis - Coggle Diagram
Software Requirements Analysis
Professional Skills
Software Cycle and Tools
The Software Development Cycle
Planning
Analysis
Design
Implementation
Testing & Integration
Maintenance
Tools
Confluence
Zoom
Slack
Canvas
Process and Software Requirements
Computer software is the product that software professionals build and then support over the long term
Software Engineering refers to a process, a collection of methods and an array of tools that allow professionals to build high-quality computer software. It is important because it enables us to build complex systems in a timely manner and with high quality
Before you begin any technical work, it's a good idea to create a set of requirements for any engineering tasks. These tasks lead to an understanding of what the business impact of the software will be, what the customer wants, and how end users will interact with the software
A
requirement
is a service, function or feature that a user needs. It focuses on functionality and how well it performs against defined parameters
Software Process Models
The Waterfall Model
Classic life cycle
A systematic, sequential approach to software development
A useful process model in situations where requirements are fixed
V-model
Depicts the relationship of quality assurance actions
Acceptance Testing that is conducted by the customer in an effort to test all required features and functions
The Spiral Model
Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
Prototyping as a risk reduction mechanism
The Formal Methods Model
To specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation (mathematical analysis)
Important for safety-critical systems
However, time consuming, expensive, difficult to use as a communication mechanism for technically unsophisticated customers
Agile Development
Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
An agile team recognises that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project
Extreme Programming
Scrum
Iterative to use multiple passes to improve (sprints)
Incremental to build some of it before you build all of it
Organises work in iterations or cycles of up to a calendar month called sprints
Treats requirements very differently from sequential product development
Views requirements as an important degree of freedom that we can manipulate to meet our business goals
Just in time and just enough for the teams to start building functionality to support that requirement
Expects the specifics to change as time passes and as we learn more about what we are building
Because of this, avoids overinvesting in requirements that we might later discard
Scrum Team
Product Owner: responsible for what will be developed and in what order
Scrum Master: helps everyone involved understand and embrace the scrum values, principles, and practices
The Development Team: self-organises to determine the best way to accomplish the goal set out by the product owner
Kanban: Visual Cards
Technical Writing
Range of formality
Informal: e.g. natural language
Advantages
No limitations in expresiveness
No communication barrier
No special training required
Disadvantages
Inherently ambigous
Prone to many types of defect types such as errors or flaws
Semi-formal: e.g. domain diagrams
Formal: e.g. logic or maths based languages
Errors in requirements
Omission: not stated by any requirement, very hard to detect
Completeness: requirement documentation should ensure that the system-to-be will satisfy all its objectives
Contradiction: requirements defining a problem space feature in an incompatible way
Consistency: compatibility of all requirements, assumptions and domain properties
Inadequacy: requirement not adequately stating a problem world feature
Adequacy: requirements address the actual needs system-to-be and correctly describes laws in the problem space
Ambiguity: requirement allowing a problem space feature to be interpreted in different ways
Unambiguity: requirements formulated in a way that has only one interpretation
Unmeasurability: requirement stating a problem world feature in a way that cannot be compared/tested/verified
Measurability: requirements formulated at a level of precision that enables evaluation/verification
Flaws in requirements
Noise: useless or irrelevant piece of information
Silence: lack of information, a notion that has not been explained
Over specification: too many details about the solution (drifts toward the conception)
Unfeasibility: cannot be realistically implemented within the assigned budget, schedule or development program
Unintelligibility: stated in an incomprehensible way for those who need to use it
Poor structuring: not organised according to any sensible and visible structuring rule
Forward reference: making use of problem space features that are not defined yet
Remorse: stating a problem world feature too late or incidentally
Poor modifiability: modification may need to globally propagated throughout the specification
Opacity: rationale, authoring or dependencies are invisible
Formal Methods
Formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software
Vending Machine Example
They provide a method for verifying that a critical system will operate according to its specification
Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily - not through ad hoc review, but through the application of mathematical analysis
Currently quite time consuming and expensive as few software developers have the necessary background to apply, extensive training is required and it is difficult to use the models to communicate to technically unsophisticated customers
However, they can be created to reduce mistakes as mistakes create rework which takes time and increases cost
Requirements Engineering
The broad spectrum of tasks and techniques that lead to an understanding of requirements
7 Phases
Inception
Initial meeting where a basic understanding of the problem is established, business needs are identified, and nature of the solution is identified
Communicating with people who want a solution
More on Inception
Asking the first questions should be "context free"
Identifying stakeholders, anyone who benefits in a direct or indirect way from the system
To gain a better understanding of the problem
How would you characterise "good" output that would be generated by a successful solution?
What problem(s) will this solution address
Can you show/describe the business environment in which the solution will be used?
Will special performance issues or constraints affect the way the solution is approached
Elicitation
Establish business goals
Engage with stakeholders to understand their goals
The objectives with regard to the limitations of the current system and the opportunities to be exploited
Establish user goals of the new software
Define the scope
More on Elicitation
Interviews
Select a stakeholder, organise a meeting, prepare an agenda and questions, a facilitator controls the meeting, and someone else takes the minutes. Afterwards, write a summary and submit both the summary or minutes to the interviewee for validation and refinement
3 kinds of interviews
Structured Interview: revolves around a focused discussion where pre-established questions are asked to the interviewee
Unstructured Interview: revolves around a free, informal discussion where there are no pre-established questions but instead an exploration of issues is conducted
Mixture of the 2: starts off with a structured interview but progresses into an unstructured interview. This is usually done to elaborate on the answers given from the initial questions
Interviewing Guidelines
Come prepared, do background research
Break the ice
Ask permission to record
Introduce context and motivation
Ask easy questions first
Do appear as a partner at all times
Be focused and keep open-ended questions for the end
Be open-minded
Ask why questions about decision made/pre-established solutions without appearing to offend
Communication Principles
Listen: try to focus on the speaker's words, rather than formulating your response to those words
Someone should facilitate the activity: every communication meeting should have a facilitator to keep conversation productive
Take notes and document decisions: someone should serve as a "recorder" and write down all important points and decisions
If something is unclear, draw a picture: verbal communication can only go so far, a drawing can often provide clarity
The output
A list of customers, users and other stakeholders who participated
Objectives of the new system with regard tot he limitations of the system-as-is and the opportunities (technology) to be exploited
A bounded statement of scope of the software
Goal Model
The system-as-is: the system as it exists before the software is built into it
The system-to-be: the system as it should be when the software will be built and operated in it
Other Elicitation Techniques
Background Study
Learn about the client
Learn about the domain (an area of interest)
Learn about the system-as-is
Questionnaires
Allows us to acquire subjective information promptly, at low cost, remotely and from a large number of people
Consists of submitting a list of specific questions to selected stakeholders
Potential bias: sample of people may not be random, and the subset of people who were willing to respond may not be random
Generally considered as a useful complement to interviews
Observations
Observing a user's workflow in the task environment
When asking users to describe how they do their jobs, it may not be precise, tasks are complex and hard to remember every minute detail
These tasks may be so habitual that they don't even think about it
Brainstroming
Generic term for having groups develop ideas. Clearly formulate the question to be solved. All about free thinking
Must be facilitated
Important to get visual with ideas
Let individuals work alone first then ask everyone to present ideas
Collecting input from too few representatives or hearing the voice of only the loudest, most opinionated customer is a problem. Requirements are about what the system has to do, whereas how the solution will be implemented is the realm of design
Elaboration
Develop a refined requirements model that identifies various aspects of software function, behaviour, and information
Develop personas in narrative, scenario-based approach to design
Perform requirements analysis to develop user scenarios that describe how the end user will interact with the system
More on elaboration: Personas
Negotiation
It isn't unusual for customers and users to ask for more than can be achieved, given limited business resources
Different customers or users to propose conflicting requirements where we reconcile these conflicts through a process of negotiation
We can do this by ranking requirements and then discuss conflicts in priority
More on Negotiation
Inconsistencies
Terminology clash: same concept, different name
Handling - use a glossary of terms that everyone agrees to
Designation clash: same name, different concepts
Handling - use a glossary
Structure clash: same concept, different structure
Handling - use a glossary
Strong conflict: statements that cannot be satisfied together
Handling - negotiation
Weak conflict: statements that aren't satisfied under some condition
Handling - negotiation
Conflict Management Process
Identify conflicts
Analyse conflicts
Generate conflict resolutions
Document conflict resolutions
Specification
Written document (e.g. Software Requirements Specification)
A set of graphical models (e.g. Goal Model, UML)
A formal mathematical model (e.g. Formal Methods)
A collection of usage scenarios (e.g. User Stories)
A prototype
Or any combination of the above
Validation
The work products produced as a consequence of requirements engineering are assessed for quality during a validation step
The specification is assessed for quality
All software requirements have been stated unambigiously that inconsistencies, omissions, and errors have been detected and corrected
More on Validation
The process of checking that requirements defined for development, define the system that the customer really wants
A review of the requirements model addresses a few questions
Happens as soon as specification/documentation is (partially) completed
Are we building the right product?
Approaches
Queries on a requirements database
Animation-based validation
Formal verifications
Inspections and reviews
Traceability is a software engineering term that refers to documented links between software engineering work products
A traceability matrix allows a requirements engineer to represent the relationship between requirements and other software engineering work products. Rows are labeled using requirement names and columns can be labeled with the name of a software engineering work product. A matrix cell is marked to indicate the presence of a link between the two
Management
Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system
Identify, control, and track requirements and changes to requirements
Types of Requirements
Functional
The functional effects that the software-to-be is required
Addresses the "WHAT" aspects
Examples
Non-functional
Quality requirements: constraints on the way the software-to-be should satisfy its functional requirements, addresses the "HOW WELL" aspects e.g. performance, security
Safety: rule out software effects that might result in accidents, degradations or losses
Security: prescribes the protection of system assets against undesirable behaviours
Confidentiality requirements: some sensitive information may never be disclosed to unauthorised parties
Integrity requirements: some information may be modified only if correctly done and with authorisation
Availability requirements: some information or resource can be used at any point in time when it is needed and its usage is authorised
Reliability: constrain the software to operate as expected over long periods of time
Performance: constrain the software's operational conditions
Interface: input/output formats and interaction sequences should be compatible with what the environment expects
Accuracy: constrain the state of the information processed by the software to reflect the state of the corresponding physical information accurately
Compliance requirements: prescribe software to conform to national laws, regulations, social norms, cultural or political constraints, and standards
Architectural requirements: Impose architectural requirements on the software-to-be. e.g. Installation, distribution
Developmental requirements: constrains the way it should be developed. Requirements on development costs, delivery schedules, variability of features, maintainability, reusability, and portability
Non-traditional - Emotional requirements
Software Requirements
Motivational/Goal Model
Goal-oriented Requirements Engineering
Advantages
From goals, one can systematically derive requirement and object models
Goals give the rationale to reqeuirements
A goal graph gives traceability from strategic concerns to technical details
Goal formalisation can prove if the refinements are correct and complete
Goal refinement structure can indicate a comprehensible structure
Disadvantages
Unless rigourous automated reason is used with formal methods, an abstract model may go unquestioned
Records contain vague intentions without thinking properly about the practical applications
Motivational Modelling
Lightweight and efficient process to understand an organisation, project, product or individual with higher abstraction level than traditional models
Do/be/feel method
Construct 4 lists
What does the solution
do
?
What qualities do we want the solution to
be
?
How do we want the users to
feel
?
Who
are we creating this solution for?
Goal Model
7 Step Process
Review the lists
Cluster the elements
Establish the do hierarchy
Add elements from the who list
Add elements from the be list
Add elements from the feel list
Consult with the user
Personas
Personas are descriptive models of our users. We want to think about how users behave, how they think, what they wish to accomplish and why
They are user models, not real people. Typical users based on our collected information of real people
You will have a diverse range of requirements, the key is to choose the right users to design for. Those users whose needs best represent the needs of a larger set of users to focus your thinking
Strengths
Tells us what the software should do
Provide a common language for discussing design decisions and also help keep the design centered on users
Design choices can be tested on a persona
Gives a clear idea of who a "user" is
Focus to design for the "user" instead of the own goals of the developer
Focus on the typical "user" which represents the majority of your users instead of the edge cases
Constructing Personas
Identify variables that differentiate distinct aspects of observed behaviour
What activities the user does
What attitude the user has
What education and training the user has; capability to learn
Why the user is engaged in the product domain
What the user's capabilities are related to the product domain and technology
Map interview subjects (users) to behavioural variables (along a measurement meter)
Identify significant behaviour patterns
Synthesize characteristics and relevant goals of the personas
Check for completeness and redundancy of the personas
Prioritise the personas to determine which should be the primary design target
Persona Types
Primary: the primary target for the design
Secondary: has specific additional needs
Customer: address the needs of customers, not end users
Served: not users, but directly affected by the use of the product
Negative: specific types of users that the product is not being built to serve, this should definitely not be the design target
Design Thinking
A process that you go through to create solutions that will actually be adopted by people
Human-centered design
A mindset that overlays design thinking to ensure that the products are actually relevant and beneficial in the long run and for the people they are intended to serve
Design steps
Empathise (Inspiration - Diverge): Learn about the audience. We should not rush to get to execution
Define (Ideation - Converge): Sharpen key questions. Converge stakeholders to better understand their needs, assets and opportunities, aligned with the one common problem
Ideate (Ideation - Diverge):Brainstorm and create solutions. HCD recommends techniques on how to generate more ideas
Prototype (Implementation - Converge): Build representations of one ore more ideas. HCD recommends tools to help us building prototypes
Test (Resets to Inspiration): Test ideas and gain user feedback. Can we make sure the end-users will use the solution? Is this MVP making things better/easier?
Usability
A quality attribute that assess how easy user interfaces are to use
5 Quality Components
Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
Efficiency: Once users have learned the design, how quickly can they perform tasks?
Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
Satisfaction: How pleasant is it to use the design?
Prototypes
Low-fidelity (Paper) Prototypes
A technique that consists of creating hand drawings of user interfaces in order to enable them to be rapidly designed, simulated and tested
Roles
Real users: these users will interact with the paper version of the system
A facilitator: a usability professional; it will introduce contexts/tasks to real users
A human computer: a person responsible for manipulating the paper prototype; this person does not interact with real users
Observers: members of the development team who take notes, observe and interpret users' interactions
Advantages
You can test workflow, specific UI components, page hierarchy, type legibility, image quality, as well as engagement
You can make design changes more easily during the test based on the extent of the design
Stakeholders recognise that the work isn't finished yet
Less time to prepare a static prototype, more time to work on design, before the test
High-fidelity (Digital) Prototypes
Purpose
Enables the client to interact with the system
Important that the client understands that they are only the skeleton of the system
Risk of clients believing that it's the final thing
Ideation: produce as many potential solutions as possible
For usability testing: users perform tasks on the digital prototype based on certain scenarios
3 Roles: same as paper prototype but no need for human computer
Top 5 Credibility Factors
Design Look
Information Design & Structure
Information Focus
Company Motive
Usefulness of the Information
Low-fidelity doesn't show colours, images, meaningful content, better fonts whereas high-fidelity do
Starts getting into UI design territory, closer to what the final version would look like with realistic data and images
Prototypes are used to
Get more user data before you code
Observe the human interaction with user interfaces even before those interfaces are designed and developed
Communicate ideas between designers, developers, users and other stakeholders in the first stages of the user-centered design process
User Stories
A user story is a brief description of the user and his or her core need. They are narrative descriptions of user roles or personas using a product to achieve specific goals
As a <User Role>, I want to <Goal> so that <Benefit>
As a [persona]: Who are we building this for? We're not just after a job title, we're after the persona of the person
Wants to: Here we're describing their intent - not the features they use. What is it they're actually trying to achieve?
So that: How does their immediate desire to do something fit into their bigger picture? What's the overall benefit they're trying to achieve? What is the big problem that needs solving?
INVEST guidelines
Independent: independent or at least only loosely coupled with one another
Negotiable: the details of the stories should be negotiable
Valuable: needs to be valuable to a customer, user, or both
Estimatable: should be estimatable by the team that will design, build, and test them
Sized appropriately: user stories worked on in sprints should be smalle
Testable: user stories should be testable in a binary way - they either pass or fail
User Scenarios
A detailed description of what users do with the product and more importantly why they do it
Describes an experience, focusing on people, and how they think and behave
Context Scenarios: a day in the life scenario that is used to explore, at a high level, how the product can best serve the needs of the personas
Key path scenario: a context scenario can be revised by more specifically describing user interactions with the software. These scenarios focus on the most significant user interactions
Types of scenarios
A
positive scenario
illustrates what should happen in terms of one behaviour that the system should cover
A
negative scenario
is a counter-example; it illustrates what may not happen in terms of one behaviour that the system should exclude
Strengths
Can be used easily by stakeholders with different backgrounds to build a shared understanding
Can be used as test cases
Limitations
They are inherently partial; as they are just examples, they do not cover all possible system behaviours under all possible circumstances
Too early of a use of scenarios can introduce some risk of over specification
Use Cases
A use case consists of a series of actions that a user must initiate with the system to carry out some useful work and to achieve their goal
A use case is a sequence of transactions performed by a system that produces a measurable result for a particular actor
A complete set of use cases = system requirements
User stories are a short description of what your user will do when they come to your website or use your software whereas use cases are a more detailed description of a set of interactions between the system and one or more actors, where an actor is either a user or another system.
Acceptance Criteria & Acceptance Tests
Acceptance Criteria
A pass/fail set of criteria that the user story must meet in order to be considered complete/done
Given <Condition, when <something happens>, then <result>
1-3 per user story
Each one is independently testable
It focuses on the end result - What. Not the solution approach - How
The developer of the user story uses to decide when they are ready to pass on the code for testing
Acceptance Tests
A process of verifying that a solution works for the user
The goal of this is to assess if the system can support day-to-day business and user scenarios and ensure the system is sufficient and correct for business usage
Follows the acceptance criteria
Cover all key business functionalities
Define scenarios of usage: e.g. book an appointment for Thursday 12 April at 9:30am with Doctor Smith at the Parkville Clinic
Two ways of running it with the client: demo based (you run it) or user driven (the client runs it)
At the end of other testing, instance of the acceptance criteria
Step by step scenario
Mood Boards & Wireframing
A mood board is a type of visual presentation or a collage consisting of images, text and samples of objects in a composition. It can be based on a set topic or can be any material chosen at random. A mood board can be used to convey a general idea or feeling about a particular topic.
A wireframe is a layout of a web page that demonstrates what interface elements will exist on key pages
User Journeys
Visualisation that tells a narrative of the end user trying to accomplish a specific task or goal as it pertains to your company
Scenario depicting how a user/customer interacts with the existing product or product being designed
Used in 2 scenarios
Demonstrating the way users currently interact with the product
Demonstrating the way users could interact with the product
Generally after creating the personas