1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a...
-
Upload
stephen-dalton -
Category
Documents
-
view
220 -
download
0
Transcript of 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a...
![Page 1: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/1.jpg)
1
Requirements/Systems analyst
• Person performing the tasks of determining the requirements for a proposed software system– (problem analysis) breaking down what the
customer wants into discrete requirements
![Page 2: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/2.jpg)
2
Requirements
• Goal of requirements phase– understand the customer’s problems and needs
• What is requirements?– An expression of desired behaviour
– Deals with objects/entities, states they can be in, and functions that are performed to change state or object characteristics
– Designates what behaviour the customer wants without saying how the behaviour will be realised
![Page 3: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/3.jpg)
3
Specification and Design
• Specification makes decisions on which requirements will be fulfilled by our software system– As opposed to those that are addressed by
special purpose hardware devices, by other software systems or by human operator or users
• In design, a plan is devised as to how the specified behaviour will be implemented
![Page 4: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/4.jpg)
4
Requirements process
![Page 5: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/5.jpg)
5
Requirements Process - Elicitation
• Collecting the user requirements by:– Asking questions– Examining current behaviour– Demonstrating similar systems
![Page 6: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/6.jpg)
6
Requirements Process - Analysis
• Understanding and modelling the desired behaviour– Modelling or prototyping the requirements helps us to
better understand the required behaviour
– Also raises additional questions about what the customer wants to happen in certain situations
• May expose problems or omissions in our models that cause us to revisit the customer and revise our models
![Page 7: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/7.jpg)
7
Requirements Process - Specification
• Documenting the behaviour of the proposed software system– Requirements are well understood– Then it is decided which parts of the required
behaviour will be implemented in this software system
![Page 8: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/8.jpg)
8
Requirements Process - Validation
• Checking that our specification matches the user’s requirements– Matches developer’s specifications with user’s
expectations of the final product
• May expose problems or omissions in our specifications that cause us to revisit the customer and revise our specifications
![Page 9: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/9.jpg)
9
Requirements Process – Software Requirements Specifications
• Eventual outcome of the requirements process
• Is used to communicate to the other software developers (designers, testers, maintainers) how the final product ought to behave
![Page 10: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/10.jpg)
10
Requirements Elicitation
• Critical part of the process
• Must use a variety of the techniques to determine what the users and the customers really want
• Discussion with everyone who has a stake in the system and coalescing these different views into a coherent set of requirements
![Page 11: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/11.jpg)
11
Stakeholders in Requirements Elicitation Process
1. Clients
2. Customer
3. Users
4. Domain Experts
5. Market Researchers
6. Lawyers or auditors
7. Software engineers or other technology experts
![Page 12: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/12.jpg)
12
Stakeholders in Requirements Elicitation Process
• Clients– Pay for software to be developed– Ultimate stakeholders as they have final say on what product
does
• Customers– Buy software after it is developed
• Users– Experts on how current system works (most useful features,
features that need improvement)– Need to understand particular needs of special groups
(differently-abled individuals, persons unfamiliar with computers, expert users)
![Page 13: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/13.jpg)
13
Stakeholders in Requirements Elicitation Process
• Domain experts– Familiar with the problem that software must automate
(financial expert for a financial package, meteorologist for software to model weather)
– Also know about kinds of environment to which product will be exposed
• Market Researchers– Conduct surveys to determine future trends and
potential customers’ needs
![Page 14: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/14.jpg)
14
Stakeholders in Requirements Elicitation Process
• Lawyers/auditors– Familiar with government, safety or legal requirements
(tax expert ensures payroll package adheres to tax law, experts on standards which are relevant to product’s functions)
• Software Engineers/other technology experts– Ensures that the product is technically and economically
feasible– Educate customer about innovative technology,
recommend new functionality taking advantage of these technologies, and can estimate cost and development time
![Page 15: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/15.jpg)
15
Techniques for Eliciting Requirements
1. Interviewing stakeholders
2. Reviewing available documentation
3. Observing current system (if one exists)
4. Apprenticing with users
5. Interviewing users/stakeholders in groups
6. Using Domain-specific strategies
7. Brainstorming
![Page 16: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/16.jpg)
16
Techniques for Eliciting Requirements
• Interviewing stakeholders– To capture the many views of the system and how it
should work
• Reviewing available documentation– Documented procedures of manual tasks– Specifications or user manuals of automated system
• Observing current system (if one exists)– Gather objective information about how users perform
their tasks– Better understand the system that the developers are
about to automate or change
![Page 17: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/17.jpg)
17
Techniques for Eliciting Requirements
• Apprenticing with users– Learn more about users’ tasks in more detail as the user
performs them
• Interviewing users/stakeholders in groups– So that they will be inspired by one another’s ideas
• Using domain-specific strategies– To ensure that stakeholders consider specific types of
requirements that are relevant to their particular situations
• Brainstorming with current and potential users about how to improve the proposed product
![Page 18: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/18.jpg)
18
Types of Requirements – Functional Requirements
• Describes a required behaviour in terms of required activities– e.g. reactions to inputs, states of each entity
before and after an activity occurs
• Defined boundaries of a solution space for our problem– Solution space is the set of possible ways that
software can be designed to implement the requirements
![Page 19: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/19.jpg)
19
Types of Requirements – Quality / Non-Functional Requirements
• Describes some quality characteristic that the software solution must posses– e.g. fast response time, ease of use, high
reliability and low maintenance costs
• Design criteria that can be optimised and used to choose among alternative implementations of functional requirements
![Page 20: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/20.jpg)
20
Make Requirements Testable
• Make requirements testable so the conclusion of whether or not a proposed solution meets the requirement, must not vary according to who is doing the evaluation
• Fit criteria– Objective standards for judging whether a
proposed solution satisfies the requirements
![Page 21: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/21.jpg)
21
Constraints on Requirements – Design Constraints
• Design constraint– Design decision that has already been made and that
restricts the set of solutions to our problem• e.g. choice of platform or interface components
• Process constraint– Restriction on the techniques or resources that can be
used to build the system• e.g. customer may insist that we use agile methods, so that
they can use early versions of the system while we continue to add features
![Page 22: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/22.jpg)
22
Requirements Problem - Conflict
• May encounter conflicting ideas of what requirements ought to be, when eliciting from stakeholders
• Possible solutions are– Ask customer to prioritise requirements– Negotiation
![Page 23: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/23.jpg)
23
Conflict Solutions – Customer prioritises requirements
• Helps customer reflect on which of requested services and features are most essential
• Loose prioritisation scheme separates requirements into 3 categories– Essential Requirements that absolutely must be met
– Desirable Requirements that are highly desirable but not necessary
– Optional Requirements that are possible but could be eliminated
![Page 24: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/24.jpg)
24
Conflict Solutions – Negotiation
• Requires skills, patience and experience in finding mutually acceptable solutions
• With effective negotiation, stakeholders will– understand and appreciate each other’s
fundamental needs and– strive for a resolution that satisfies everyone
![Page 25: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/25.jpg)
25
Different Purposes of Requirements
Requirements analysts and their clients
To explain their understanding of how the system would behave
Designers As constraints on what would be considered an acceptable solution
Test team To derive a suite of acceptance tests
Maintenance team To help ensure that the system enhancements do not interfere with the system’s original intent
![Page 26: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/26.jpg)
26
Requirements Documents1. Requirements Definition
– Aimed at a business audience, such as clients, customers and users– Complete listing of everything customer wants to achieve– Written entirely in terms of environment, describing how the
environment will be affected by the proposed system
2. Requirements Document– Aimed at a technical audience, such as designers, testers and
project managers– Restates requirements as a specification of how proposed system
will behave– Written entirely in terms of environment, except that refers solely
to environmental entities that are accessible to the system via its interface
![Page 27: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/27.jpg)
27
Characteristics of Requirements
1. Correctness
2. Consistency
3. Unambiguity
4. Completeness
5. Feasibility
6. Relevance
7. Testability
8. Traceability
![Page 28: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/28.jpg)
28
Characteristics of Requirements
1. Correctness• Developer and customer should ensure conformity to
our understanding of the requirements
2. Consistency• No conflicting requirements, as inconsistent
requirements cannot be satisfied simultaneously
3. Unambiguity• Multiple readers of requirements should have
different but valid interpretations
![Page 29: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/29.jpg)
29
Characteristics of Requirements
4. Completeness• Set of requirements is defined as complete if it
specifies required behaviour and output for all possible inputs in all possible states under all possible constraints
• Externally complete if all states, state changes, inputs, products, and constraints are described by some requirement
• Internally complete if there are no undefined terms among the requirements
![Page 30: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/30.jpg)
30
Characteristics of Requirements5. Feasibility
• Existence of a solution to customer’s need
6. Relevance• Indirectly related to customer’s need or may restrict developers
unnecessarily
7. Testability• Existence acceptance tests that would clearly demonstrate whether
the eventual product meets the requirements
8. Traceability• Organisation of requirements for easy reference• There should be correspondence between every entry in the
requirement definition and requirements specification, and vice versa
![Page 31: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/31.jpg)
31
Purpose of characteristics
• Help in making the decision when we have collected enough information
• Also when we need to learn more about what a particular requirement means
![Page 32: 1 Requirements/Systems analyst Person performing the tasks of determining the requirements for a proposed software system –(problem analysis) breaking.](https://reader035.fdocuments.net/reader035/viewer/2022062518/56649e175503460f94b0203a/html5/thumbnails/32.jpg)
32
Purpose of characteristics
• The degree to which we want to satisfy these characteristics will affect:– Type of information that we gather during
requirements elicitation, and how comprehensive we want to be
– Specification language we choose to express the requirements and the validation and verification checks that we eventually perform to assess the requirements