Requirements Analysis
(license) |
(updated Directions heavily) |
||
Line 6: | Line 6: | ||
|'''Overview''' || Students will create and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project. | |'''Overview''' || Students will create and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project. | ||
|- | |- | ||
− | |'''Prerequisite Knowledge''' || It would be helpful | + | |'''Prerequisite Knowledge''' || It would be helpful for students to be familiar with the Software Development Life Cycle (SDLC), and its various models and phases, which often includes Requirements. The difference between plan-based methods like Waterfall, and iterative approaches like Agile will allow students to see the very different methods of requirements gathering. |
|- | |- | ||
|'''Learning Objectives''' || Upon completion, students should: | |'''Learning Objectives''' || Upon completion, students should: | ||
Line 17: | Line 17: | ||
Background reading material: | Background reading material: | ||
* https://en.wikipedia.org/wiki/Requirements_analysis | * https://en.wikipedia.org/wiki/Requirements_analysis | ||
+ | * https://www.acm.org/education/CS2013-final-report.pdf#page=178 Bottom of Page 178 (Page 181 marked in the PDF) | ||
* https://www.atlassian.com/agile/requirements/ | * https://www.atlassian.com/agile/requirements/ | ||
* http://news.slashdot.org/story/00/10/23/1250228/gathering-requirements-in-open-source-projects | * http://news.slashdot.org/story/00/10/23/1250228/gathering-requirements-in-open-source-projects | ||
Line 23: | Line 24: | ||
What is the rational for this activity? | What is the rational for this activity? | ||
− | As software development migrates from Waterfall to Agile / Iterative development models, it will be important to understand how | + | As software development migrates from Waterfall to Agile / Iterative development models, it will be important to understand how requirements fits into each. Open source projects often have a less formal requirements gathering process than say a government contract job, but it is still there behind the covers. Students should be aware of how requirements are gathered in a distributed diverse community, versus a single central authority. |
=== Directions: === | === Directions: === | ||
− | + | * After reading background docs, have students explain how requirements are held and managed in both traditional waterfall SDLC methods and agile / iterative SDLC methods | |
+ | * Now, show students the two requirements / features / issue tracker. Give context so that they know was community and one was an offshoot team | ||
− | + | * Have students document and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project | |
+ | ** Give the students a template paper that they must fill out (make a simple PDF) | ||
+ | ** Where did the requirement start its life? What did it look like? Who reported it? | ||
+ | ** Repeat this for each major step of the life (talk forum to github issue to code) | ||
+ | * Have students compare the two requirement examples given | ||
+ | ** Why do you think requirements were done in a different way? | ||
+ | ** What did one method gain or lose over the other? | ||
− | ManageIQ (RH Cloudforms) | + | |
− | ManageIQ Github Issues and Creating new Issues | + | * ManageIQ (RH Cloudforms) |
− | ManageIQ Trello / Task board | + | ** ManageIQ [https://github.com/ManageIQ/manageiq/issues/ Github Issues] and [http://manageiq.org/community/issues/ Creating new Issues] |
− | Discourse tool and Feature discussions | + | ** ManageIQ [https://trello.com/b/UeTqKlp3/manageiq-roadmap Trello / Task board] |
− | ManageIQ team (if I want to mention it in passing - just a neat resource to show) | + | ** [http://talk.manageiq.org/ Discourse tool] and Feature discussions |
− | Examples: | + | ** ManageIQ [http://manageiq.org/community/team/ team] (if I want to mention it in passing - just a neat resource to show) |
− | Git Integration Feature discussion, bug, code 1, 2, more? | + | |
− | Chargeback Feature discussion, requirements, bug? | + | |
− | + | * 2 Requirements Examples: | |
+ | ** Git Integration Feature [http://talk.manageiq.org/t/version-control-integration/414 discussion], [https://github.com/ManageIQ/manageiq/issues/1199 bug], [https://github.com/ManageIQ/manageiq/pull/1204 code 1], [https://github.com/mkanoor/manageiq/commit/9c889c0269f25e3823dbae2b93b1120ea3e70538 2], more? | ||
+ | ** Chargeback Feature [http://talk.manageiq.org/t/chargeback-open-discussion/440/10 discussion], [https://github.com/rhus/charging-docs/wiki/Requirements:-Collection-and-Mediation requirements], [https://bugzilla.redhat.com/show_bug.cgi?id=1052106 bug?] | ||
Revision as of 08:17, 29 January 2016
Title | Requirements Analysis |
Overview | Students will create and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project. |
Prerequisite Knowledge | It would be helpful for students to be familiar with the Software Development Life Cycle (SDLC), and its various models and phases, which often includes Requirements. The difference between plan-based methods like Waterfall, and iterative approaches like Agile will allow students to see the very different methods of requirements gathering. |
Learning Objectives | Upon completion, students should:
|
Background:
Background reading material:
- https://en.wikipedia.org/wiki/Requirements_analysis
- https://www.acm.org/education/CS2013-final-report.pdf#page=178 Bottom of Page 178 (Page 181 marked in the PDF)
- https://www.atlassian.com/agile/requirements/
- http://news.slashdot.org/story/00/10/23/1250228/gathering-requirements-in-open-source-projects
- https://books.google.com/books?id=-GmZBgAAQBAJ&pg=PA20&lpg=PA20
- http://programmers.stackexchange.com/questions/175766/how-are-requirements-determined-in-open-source-software-projects
What is the rational for this activity? As software development migrates from Waterfall to Agile / Iterative development models, it will be important to understand how requirements fits into each. Open source projects often have a less formal requirements gathering process than say a government contract job, but it is still there behind the covers. Students should be aware of how requirements are gathered in a distributed diverse community, versus a single central authority.
Directions:
- After reading background docs, have students explain how requirements are held and managed in both traditional waterfall SDLC methods and agile / iterative SDLC methods
- Now, show students the two requirements / features / issue tracker. Give context so that they know was community and one was an offshoot team
- Have students document and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project
- Give the students a template paper that they must fill out (make a simple PDF)
- Where did the requirement start its life? What did it look like? Who reported it?
- Repeat this for each major step of the life (talk forum to github issue to code)
- Have students compare the two requirement examples given
- Why do you think requirements were done in a different way?
- What did one method gain or lose over the other?
- ManageIQ (RH Cloudforms)
- ManageIQ Github Issues and Creating new Issues
- ManageIQ Trello / Task board
- Discourse tool and Feature discussions
- ManageIQ team (if I want to mention it in passing - just a neat resource to show)
- 2 Requirements Examples:
- Git Integration Feature discussion, bug, code 1, 2, more?
- Chargeback Feature discussion, requirements, bug?
Deliverables:
What will the student hand in?
Assessment:
How will the activity be graded?
How will learning will be measured?
Include sample assessment questions/rubrics.
Criteria | Level 1 (fail) | Level 2 (pass) | Level 3 (good) | Level 4 (exceptional) |
---|---|---|---|---|
Understanding of requirements in context of wider SDLC | ||||
Explains common methods and tools in oss req. gathering | ||||
Can track requirements from initial sources through to code |
Comments:
What should the instructor know before using this activity?
What are some likely difficulties that an instructor may encounter using this activity?
Additional Information:
ACM Knowledge Area/Knowledge Unit | SE - Software Engineering / SE Requirements Engineering from ACM_Body_of_Knowledge |
ACM Topic | Requirements tracing; Describing functional requirements; Evaluation and use of requirements specifications; from https://www.acm.org/education/CS2013-final-report.pdf |
Level of Difficulty | Easy |
Estimated Time to Completion | 2-3 hrs |
Materials/Environment | Internet access |
Author | Nick Yeates |
Source | N/A |
License | Creative Commons CC-BY |
Suggestions for Open Source Community:
Suggestions for an open source community member who is working in conjunction with the instructor.
This work is licensed under a Creative Commons Attribution 4.0 International License