Requirements Analysis
2RequirementRequirement – specified functional or physical need that aparticular software must perform.SoftwareRequirement...
3Types of requirementsFunctional requirements explain what should be done. identify tasks or activities that must be met...
4Types of requirementsNon-functional requirements define the criteria of the system as awhole rather than individual behav...
5Usually software requirements are presented to theproject team in the following views:SRS (Software Requirements Specifi...
6Software Requirements SpecificationSoftware RequirementsSpecification consistsof following sections:IntroductionOverall...
7Product BacklogThe entry of a Product Backlog is a UserStory.Format:Example:A User Story is one or more sentences stat...
8Use CaseTo describe complex functional requirements(often grouped into scenarios of softwareusage), Use Cases are used i...
9Use Case Diagram
10Use Case as Structural Text Use Case’s structure Title: "goal the use case is trying to satisfy" Main Success Scenari...
11Good requirement A requirement is considered as Good One if it possessesfollowing qualities: Necessary Complete Veri...
12Thank You!
Upcoming SlideShare
Loading in...5
×

Requirements presentation

107

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
107
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Requirements presentation"

  1. 1. Requirements Analysis
  2. 2. 2RequirementRequirement – specified functional or physical need that aparticular software must perform.SoftwareRequirementsClient ‘sIdeaClient’sBusiness NeedsRequirements origin
  3. 3. 3Types of requirementsFunctional requirements explain what should be done. identify tasks or activities that must be met define the steps that the system must be capable ofperforming, communications input/output behavior of thesystem.Example Req01: there should be a possibility to associate the .pdf,.docx, .xlsx files up to 35 KB in size with an exam record.There should be not more than 5 files associated with 1exam record.
  4. 4. 4Types of requirementsNon-functional requirements define the criteria of the system as awhole rather than individual behavior scenarios. Physical environment (equipment, multiple sites, etc.) User & human factors (who are the users, their skill level etc.) Performance (how effectively is software functioning) Documentation (what kind of documentation need to be createdfor end users) Security (backup, firewall) Others (UI and technical design, architectural constrains, etc )Example Req02: with 100 concurrent users file upload time should be lessthan 1 sec for any of the .pdf, .docx, .xlsx files up to 35 KB in size.
  5. 5. 5Usually software requirements are presented to theproject team in the following views:SRS (Software Requirements Specification)a document that lists all requirements to asoftware, grouped by type into logical sectionsProduct Backloga list of requirements (called User Stories) that ismaintained for a product developed using the AgileSDLC (Scrum) methodologyRequirements view
  6. 6. 6Software Requirements SpecificationSoftware RequirementsSpecification consistsof following sections:IntroductionOverall descriptionSpecific requirementsSupporting information
  7. 7. 7Product BacklogThe entry of a Product Backlog is a UserStory.Format:Example:A User Story is one or more sentences statedin the everyday language of the end user thatcaptures what a user does or needs to do aspart of his or her job function.
  8. 8. 8Use CaseTo describe complex functional requirements(often grouped into scenarios of softwareusage), Use Cases are used instead of plaintext.Use Cases might be represented in two majorforms:DiagramStructural textual descriptionA Use Case is a list of steps, typically defininginteractions between a role (known in UML as an"actor") and a system, to achieve a goal. The actorcan be a human or an external system.
  9. 9. 9Use Case Diagram
  10. 10. 10Use Case as Structural Text Use Case’s structure Title: "goal the use case is trying to satisfy" Main Success Scenario: numbered list of stepsStep: "a simple statement of the interaction betweenthe actor and a system Extensions: separately numbered lists, one per ExtensionExtension: "a condition that results in differentinteractions from .. the main success scenario". Anextension from main step 3 is numbered 3a, etc. Use Case’s structure might be tailored to projects need
  11. 11. 11Good requirement A requirement is considered as Good One if it possessesfollowing qualities: Necessary Complete Verifiable Unambiguous Consistent Example: Req03: when a user accesses any screen, it must appearon the monitor within 1 second.
  12. 12. 12Thank You!

×