Scribd
Upload
33 views

CSE327 Lecture 2 MMA1

The document provides information on types of requirements for software engineering projects, including functional requirements, non-functional requirements, and constraints. It also discusses best practices for collecting requirements such as interviewing users, using questionnaires, prototyping, observation, and reviewing documents and user stories. User stories are described as short, goal-oriented descriptions of desired system behaviors from the perspective of an end user.

Uploaded by

mdy850.my
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
33 views

CSE327 Lecture 2 MMA1

The document provides information on types of requirements for software engineering projects, including functional requirements, non-functional requirements, and constraints. It also discusses best practices for collecting requirements such as interviewing users, using questionnaires, prototyping, observation, and reviewing documents and user stories. User stories are described as short, goal-oriented descriptions of desired system behaviors from the perspective of an end user.

Uploaded by

mdy850.my
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Software

Engineering
(CSE 327)
Lecture 2
Types of Requirements
• Functional requirements: Describe the interactions between
the system and its environment independent from
implementation
– The watch system must display the time based on its location
• Nonfunctional requirements: User visible aspects of the
system not directly related to functional behavior.
– The response time must be less than 1 second
– The accuracy must be within a second
– The watch must be available 24 hours a day except from 2:00am -
2:01am and 3:00am - 3:01am
• Constraints (“Pseudo requirements”): Imposed by the client
or the environment in which the system will operate
– The implementation language must be COBOL
Properties of Requirements
• Correct
• Complete
• Consistent
• Clear, unambiguous
• Realistic
• Verifiable
• Traceable
Collecting data in the problem domain
• To understand the problem that we are dealing
with, we can adopt the following techniques
– Interview
– Questionnaire
– Experimentation by building a prototype
– Observation
– Document inspection
– User story
User Story
• User Story
– Users tell the stories, and developers listen, ask questions
to understand context
– A short description of the behaviour of the system
• Generally implementation issues are not discussed
• The entire system is specified through stories
• Each story is short, goal oriented – testable
– Can be used for usability testing
• Story is descriptive, but often a diagram or a sample
output page helps to explain the concept much
better
– As in user interface snippets, forms or reports
Data to be collected and analyzed
• Actors - role and responsibility
• Scenarios/User Stories
• Source of the data that we have to deal with
(reliability and accuracy, etc)
• Information that actors want (output)
• Software interfaces to existing actors
• What cause events to happen, and what cause work
to be created
• Workflows and activities
• Knowing what type of problem it is (solvable?)
What is a User Story?
• A User Story is a requirement expressed from the perspective
of an end-user goal.
• It’s usually written out as a couple of sentences. Most user
stories are written in the language of the users, so any user
should be able to read a user story and immediately
understand what it means.
• A User Story is really just a well-expressed requirement.
• User Story is only meant to describe a feature, but not
describe how to implement it, meaning leaving out the
technical aspect, it should describe the behavior or flow from
user’s perspective.
What is a User Story?
• The User Story format has become the most popular
way of expressing requirements in Agile for a number
of reasons:
– It focuses on the viewpoint of a role who will use or be
impacted by the solution
– It defines the requirement in language that has meaning
for that role
– It helps to clarify the true reason for the requirement

• It helps to define high level requirements without


necessarily going into low level detail too early
User Story
• User Stories are often deemed to comprise
three elements - the 3C’s
• Card
• Conversation
• Confirmation
User Story
User Story
Where are the details?
Details as conditions of satisfaction
Details added in smaller sub-stories
User Story format
• The format of the User Story is as follows:

As a < role>

I need <requirement or feature>

So that <goal / value>


User Story (Logging in)
• Confirmation
1. Success – valid user logged in and refer to home page
– a. “Remember me” ticked – store cookie/automatic login
next time.
– b. “Remember me” not ticked – force login next time.
2. Failure – display message:
– a. “Email address in wrong format”
– b. “Incorrect user name, please try again”
– c. “Incorrect password, please try again”
– d. “Service unavailable – please try again later”
– e. “Account has expired – refer to account renewal page”
Words are imprecise
Words are imprecise
Words are imprecise

You might also like