PROG8060_Lesson03_RequirementsRNHEdits.pptx

Requirement analysis doc

1. Software Requirements SENG8060 Developing Quality Applications Spring 2019 Baljeet S. Bilkhu [email protected]

2. Today’s Agenda… 2.0 Software Requirements Analysis 2.1 Recognize the role that software requirements and specifications play in software development. 2.2 Differentiate between functional and non-functional requirements for a computer application. 2.4 Analyze software requirements and specifications for completeness and correctness.

3. Background Software Requirements is the area within software development that concerns itself with the definition, specification, analysis and validation of requirements pertaining to software development. Without any requirements, we would have no idea on what we need to develop (and test). Also, poor requirements often leads to projects that have poor quality or projects that fail.

4. Background ( cont …) Provide a communication avenue between what the customers want and the developers / testers who implement the application Software Requirements also helps to define the scope of any software development project / activity to solve a problem. Requirements also need to managed at every stage of a software development project / activity to ensure that the requirements are still indeed correct and valid.

5. As well as defining the functionality requirements: Should be consistent Should be flexible Should be robust Should consider security 5 of 9

6. Requirements in Waterfall Model Requirements need to be set up front and for the most part, cannot change when using the Waterfall model.

7. Requirements in Agile Can take the form of: System Requirements Prototypes (POCs) Use Cases User Stories As requirements change (which they often do), these changes can be incorporated easier into the development cycle.

8. Developing Requirements The first step involved in developing requirements is to seek them out using the following sources: SME’s: Subject Matter Experts Domain knowledge Stakeholders within the company Business Rules Operational Environment Customers / Customer Facing Individuals

9. Developing Requirements ( cont …) Techniques need to be used to further develop Requirements: Interviews / Hall Testers Scenario simulations Proof Of Concepts Prototypes Brainstorming Meetings Competition Analysis User Stories

10. User Stories This technique is mostly used within Agile and take the vantage point from the various types of users that will be using the system For instance, a standalone application such as a Calculator, we would only have one user (called “The User”) and we would base our user stories using the following format: As a <role>, I want <goal> so that <benefit>

11. User Stories ( cont …) User Stories in Agile can essentially replace the requirements from Waterfall methodologies – they are really a well expressed and contained requirement They focus more importantly on the actual role or the user who will be using the application They define and provide insight into the true reason why the requirement is required (i.e. performing Validation)

12. User Stories ( cont …) As a User, I want to be able to add two numbers so that I can see the correct result; As a User, I want to be able to subtract two numbers so that I can see the correct result; As a User, I want to be able to multiply two numbers so that I can see the correct result; As a User, I want to be able to divide two numbers so that I can see the correct result.

13. System Context Diagram 13 of 9 By NDE - NDE Context Diagram.jpg (redrawn in SVG), Public Domain, https:// commons.wikimedia.org /w/ index.php?curid =39317877

14. Decision Tables Context Action Result User is about to register All required details are submitted User is successfully registered User is about to register Missing email Error Message User is about to register Passwords don’t match Error Message 14 of 9 This could be used as part of a process model to identify exception cases missing from user story.

15. User Stories – Hands On Work Develop a set of User Stories for an application that would allow a student to enroll into a course here at Conestoga. This same application would provide an administrator with the ability to create new courses as well as to perform maintenance on them. Students need to also meet certain pre-requisites to be able to register for a course.

16. Functional and Non-Functional Requirements When we talk about “Functional Requirements”, we are most interested in HOW the software should function. For example, with our Calculator application, we want the software to correctly show the results of every calculation. When we refer to the “Non-Functional Requirements” of an application, we are normally referring to those requirements that are used to CONSTRAIN the application behavior For example, we want to assess the performance of an app to determine the load it can handle.

17. Functional and Non-Functional Requirements Examples of Functional Requirements: The program must be able to calculate the addition, subtraction, multiplication and division of two integers Upon entering a valid userid and password, the system authenticates the user and allows them to see their credit history Examples of Non-Functional Requirements: Performance Maintainability Security, Etc …

18. Requirements Analysis The software products that we develop may consist of many moving parts – each with its own set of functions that contribute to the overall system. To be able to design, develop, implement and test our product, we need to know exactly how these parts co-exist and the details around the overall operation – this is what is known as Requirements Analysis .

19. Requirements Analysis – the Why? By analyzing requirements, we can: Detect and resolve any inconsistencies between requirements; Discovery any limitations associated with the software application; Further elaborate / define the system requirements to properly support the software related requirements For this to work effectively, we need to ensure that the requirements we define are described with enough precision and accuracy to enable them to be validated as well as their implementation to be verified (remember the ‘V’ model) Also need to ensure that the requirements are not too detailed that we get lost in the details and are unable to see the overall product from them.

20. Requirements Classification Requirements can be classified by whether they are: Functional vs. non-Functional Derived from higher level requirements Product or process / workflow related Of a certain priority for the customer Constrained by scope Volatile or changing

21. Project Work

22. Task 3: Requirements / Specifications Develop a set of Requirements / Specifications using the template provided in eConestoga for this week. Due on Friday of this week at the end of the Lab (i.e. 2:00PM) One submission per group / team Worth 10% of your overall mark – deductions will apply for any late / absentees Need to include: Purpose Overall Description System Features External Interfaces Non-Functional Requirements References Used

23. Thank You ! Any questions?