2RequirementRequirement – specified functional or physical need that aparticular software must perform.SoftwareRequirementsClient ‘sIdeaClient’sBusiness NeedsRequirements origin
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.
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.
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 sectionsProduct Backloga list of requirements (called User Stories) that ismaintained for a product developed using the AgileSDLC (Scrum) methodologyRequirements view
6Software Requirements SpecificationSoftware RequirementsSpecification consistsof following sections:IntroductionOverall descriptionSpecific requirementsSupporting information
7Product BacklogThe 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.
8Use CaseTo 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:DiagramStructural 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.
10Use Case as Structural Text Use Case’s structure Title: "goal the use case is trying to satisfy" Main Success Scenario: numbered list of stepsStep: "a simple statement of the interaction betweenthe actor and a system Extensions: separately numbered lists, one per ExtensionExtension: "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
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.