Requirements Analysis

(Difference between revisions)
Jump to: navigation, search
(added link for proj mgmt answer from manageiq)
(13 intermediate revisions by one user not shown)
Line 2: Line 2:
 
{| border="1"
 
{| border="1"
 
|-  
 
|-  
|'''Title''' || Requirements Analysis
+
|'''Title''' || Requirements Analysis (ManageIQ 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.
+
|'''Overview''' || Students will read about software requirements, delve into open source requirements tracking tools in the ManageIQ community (cloud computing), and explain a timeline of how a requirement progressed across the life of a particular feature.
 
|-  
 
|-  
|'''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.
+
|'''Prerequisite Knowledge''' || Students should 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.
 +
* (Optional) Cloud-computing, which will help in the ManageIQ example, but teachers could easily use other projects, or tell students to bypass the details of cloud computing for now.
 
|-
 
|-
|'''Learning Objectives''' || Upon completion, students should:
+
|'''Learning Objectives''' || Upon completion, students should be able to:
* understand what requirements gathering means in context with a wider software development life cycle.
+
* Understand the requirements-gathering method in context with a wider software development life cycle.
* be able to explain what common methods and tools are used in open source requirements gathering.
+
* Explain what common methods and tools are used in open source requirements gathering.
* be able to track requirements and issues and code from forums, to issue trackers, through code bases.
+
* Track requirements, issues, and code from forums, to issue trackers, to code bases.
 
|}
 
|}
  
 
=== Background: ===
 
=== Background: ===
Background reading material:
+
Background reading material is given during Part 1 of the exercise.
* 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?
+
What is the rationale 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.
+
 
 +
As software development differs between waterfall and Agile / Iterative development models, it will be important to understand how requirements fit into each model. Open source projects often have a less formal requirements-gathering process than a government contract job, but the requirements are still there in each case. Students should be aware of how requirements are gathered in a distributed diverse community.
  
  
 
=== 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
+
In this activity, you will dive into a real open source project, and study the numerous requirements-gathering development artifacts around two features of the project. First, you will read some background materials around requirements analysis. Next, you will learn about the ManageIQ project and community. Finally, you will delve into two particular features / issues / code sets in ManageIQ. You will need to illustrate the process, describe a timeline, and answer questions. Technical understanding is not needed; however pay attention to the patterns that the requirements show.
* 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
+
==== Part 1: Requirements Background ====
** Give the students a template paper that they must fill out (make a simple PDF)
+
Read the following resources and reflect on the questions below. Note:  you only need to read the pages or sections mentioned below, however  reading further will prove useful.
** 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?
+
  
 +
* [https://en.wikipedia.org/wiki/Requirements_analysis Requirements analysis overview] - Read the "Overview" and "Requirements analysis issues" sections (1 and 4); also review the "Software development process - core activities" table on the right side of the page to understand how requirements fit into the wider Software Development Life Cycle (SDLC). Where do requirements fit into the wider software development process? What other processes might requirements feed into?
 +
* [https://www.acm.org/education/CS2013-final-report.pdf ACM's quick description] - Read the bottom of Page 178 (Page 181 marked by the PDF reader) titled "SE/Requirements Engineering". What challenges should you be aware of when utilizing requirements to drive software development?
 +
* [https://www.atlassian.com/agile/requirements/ Atlassians agile requirements tips] - Read from the top of the page through the "Keeping requirements lean with a one-page dashboard" section. How does requirements-gathering differ in agile-based projects compared to more plan-driven projects (like Waterfall methodology)?
 +
* [https://confluence.atlassian.com/doc/blog/2015/08/how-to-document-product-requirements-in-confluence Example of documenting requirements] - This is one example of how to write requirements. No need to read it in-depth; simply take a look so that you can see a solid example.
  
* ManageIQ (RH Cloudforms)
+
Optional Reading: Requirements in open source - Teachers can decide if they also want to focus on requirements specific to open source. This would be advanced work rather than students simply moving onto the below hands-on sections.
** ManageIQ [https://github.com/ManageIQ/manageiq/issues/ Github Issues] and [http://manageiq.org/community/issues/ Creating new Issues]
+
** ManageIQ [https://trello.com/b/UeTqKlp3/manageiq-roadmap Trello / Task board]
+
** [http://talk.manageiq.org/ Discourse tool] and Feature discussions
+
** ManageIQ [http://manageiq.org/community/team/ team] (if I want to mention it in passing - just a neat resource to show)
+
** Forum question/answer around [http://talk.manageiq.org/t/how-are-project-mgmt-activities-done-here how ManageIQ does Project Management]
+
  
 +
* [http://news.slashdot.org/story/00/10/23/1250228/gathering-requirements-in-open-source-projects Does open source have requirements?] - Of special interest are the comments by "FortKnox" and "ivan256" where each of them give differing views on waterfall versus an iterative approach to requirements management.
 +
* [https://books.google.com/books?id=-GmZBgAAQBAJ&pg=PA20&lpg=PA20 Productization and requirements in the enterprise and open source]
 +
* [http://programmers.stackexchange.com/questions/175766/how-are-requirements-determined-in-open-source-software-projects How are requirements determined in open source software projects?]
  
* 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?]
 
  
  
=== Deliverables: ===
+
==== Part 2: ManageIQ intro ====
What will the student hand in?
+
In this activity, we will focus on the ManageIQ open source community. [http://manageiq.org/documentation/faq/#what-is-manageiq ManageIQ] is a cloud-enabled management platform ([http://www.gartner.com/it-glossary/cloud-management-platforms CMP]) that lets you: 1) monitor; 2) start/stop; and 3) analyze servers and applications in a corporate cloud infrastructure. For example, if a company decides to make its own set of cloud resources inside their own company, in a big data-room, they may have hundreds of machines to help their employees run servers and web applications. They might use ManageIQ to help keep everything under control and running smoothly. ManageIQ is made in a communal open source fashion. Keep in mind, that before Red Hat acquired them, this community ''used'' to be proprietary and closed. They have slowly been moving toward open and communal ways. This is a good ongoing lesson in how to "go open".
  
 +
===== ManageIQ development tools =====
 +
Below is a list of the tools that are used and publicly available for use by the ManageIQ project. Click on each link and observe the various uses for each tool. Why do you think there are so many tools? Give examples of how the separate tools link together to each other on occasion.
 +
* ManageIQ [https://github.com/ManageIQ/manageiq/issues/ Github Issues] and [http://manageiq.org/community/issues/ Creating new Issues]
 +
* ManageIQ [https://trello.com/b/UeTqKlp3/manageiq-roadmap Trello / Task board] - This is like a complex To-Do list; It is how they track their various requirements/issues; Open and read the upper left box titled "How this board is used: What do these Lists mean????"
 +
* [http://talk.manageiq.org/ Forum tool] - They call it "Talk" and its where many eventual Features are first introduced and discussed.
 +
* ManageIQ [http://manageiq.org/community/team/ team] - A listing of their team members. Though not directly related to requirements, you will see these team members names and handles across the various tools.
 +
* [http://talk.manageiq.org/t/how-are-project-mgmt-activities-done-here How ManageIQ does Project Management] - I asked on the talk forum for more information on how they project-manage their requirements and issues. Their [[https://en.wikipedia.org/wiki/Scrum_(software_development)#Scrum_master scrum masters] (a person who leads a team of agile developers) answer is well worth a read.
 +
* [https://www.youtube.com/playlist?list=PLQAAGwo9CYO-SEH9SW7IEwDF6-IzlB_mx Sprint Review Meetings (taped on youtube!)] - Sprint reviews are cyclical get-together meetings with stakeholders invited to show progress, review feedback, and change directions if needed.
 +
* [https://gemnasium.com/ManageIQ/manageiq Ruby Gem Dependencies] - This is a more technical tool used for tracking what other libraries their software depends on
  
=== Assessment: ===
 
How will the activity be graded?
 
 
How will learning will be measured?
 
  
Include sample assessment questions/rubrics.
 
  
 +
==== Part 3: Compare two real requirements ====
 +
Below are two features within the ManageIQ project. Requirements exist inside each features various artifacts (links below). Inspect the links in both and answer the questions below it.
 +
After the questions, you will choose one feature to describe, with diagrams and/or words, of what occurred in the progression of the requirement. See more below.
 +
 +
===== Two requirements examples: =====
 +
Listed below are two features that the ManageIQ open source project took on and implemented, or are still implementing. Do take note that the git feature started in a forum and progressed to be implemented in chunks by the central ManageIQ developers, who are mostly hired by Red Hat. On the other hand, the chargeback feature was taken up and implemented by a team of community interns. A couple of banks that use ManageIQ combined resources with Red Hat to bring in a handful of student interns to work on this special chargeback feature. They operated separate, but in-sync with the central developers. This is of note, to see similarities and differences in how they tracked requirements and implemented their code.
 +
 +
Read the various links that follow two feature examples.
 +
 +
# Git Integration Feature
 +
#* [http://talk.manageiq.org/t/version-control-integration/414 Initial Discussion] that started it. Read this in full and dont worry about understanding the technical side of it.
 +
#* [https://github.com/ManageIQ/manageiq/issues/1199 They created a Github Issue (bug)]. Notice how it links from the above discussion.
 +
#* [https://github.com/ManageIQ/manageiq/pull/1204 Code that was implemented] - Just take a look here, no need to understand it. Again, notice the connection.
 +
#* [https://github.com/mkanoor/manageiq/commit/9c889c0269f25e3823dbae2b93b1120ea3e70538 More code] - Again, just peak; Notice how the code links to the Issue.
 +
#* There is even more code, and likely more to come, that will link back to this feature. Take note that this code is implemented across a pretty lengthy time-period.
 +
# Chargeback Feature
 +
#* [http://talk.manageiq.org/t/chargeback-open-discussion/440 This discussion] seems to kick off an initial inquiry; Note the timing and note user "sergio_ocon" who later leads the team of interns to implement this
 +
#* [https://github.com/rhus/charging-docs/wiki/Requirements:-Collection-and-Mediation These set of more formal requirements] were brought together after the above discussion. Note the many additional pages linked-to off to the right in a small table of contents. Do not worry about the technical descriptions or details - simply get a feel for how they organize the requirements and content.
 +
#* [https://github.com/rhus/charging-docs Their github repository] actually contains their requirements, specifications, documentation, and code. Note the links to various other resources.
 +
#* [https://github.com/rhus/charging-docs/wiki/Bugzilla-ManageIQ This list of bugs] are all related to chargeback. This is an example of this student-intern team linking their work back to issues that the central manageIQ project has logged. Open source communities can be separate yet connected.
 +
#* [https://trello.com/b/LCtVqFob/chargeback-in-cloudforms-roadmap This trello board] tracks their development progress. It is separate from the wider ManageIQ communities trello board (linked above).
 +
#* [http://restoconstante.blogspot.com/ This blog] summarizes development milestones made on the various requirements, as well as more human-oriented commentary on the process and politics involved in the resources they used to implement this (student interns hired by customers to work on open source).
 +
 +
 +
===== Questions =====
 +
Answer the below questions after having read through the above two examples:
 +
* In what tools does the ManageIQ community keep its requirements? Do you find them in multiple places?
 +
* Recall the [http://talk.manageiq.org/t/how-are-project-mgmt-activities-done-here forum post by ManageIQ's Scrum Master]. What two tools does the central development team seem to rely on the most for tracking requirements and development progress?
 +
* Where did the git feature start its requirements? Where did they originate from? The development team? A customer? A user? Why do you think this person reported their issue?
 +
* What does the above question tell you about where communities can get their requirements? Why is it good that requirements are sometimes sourced from outside parties?
 +
* Why might getting requirements from otherwise uninvolved parties be an advantage for open source communities?
 +
 +
 +
===== Diagram =====
 +
* Now, choose one of the examples to document and explain a timeline of how the requirements progressed across the life of the feature.
 +
* You may choose to:
 +
*# simply write out the progression (in 3-5 paragraphs), or
 +
*# to illustrate it with a visual timeline or block diagram such as a flow chart
 +
*#* Examples of diagrams include [http://xmindshare.s3.amazonaws.com/preview/requirements-timeline-lysaa-1255969706300.jpg this requirements function timeline] (though you might heavily alter its categories),
 +
*#* [http://boxesandarrows.com/files/banda/case-study-of-agile/devotimeline.jpg this year-to-dev-function timeline], or
 +
*#* [https://upload.wikimedia.org/wikipedia/commons/thumb/9/91/LampFlowchart.svg/2000px-LampFlowchart.svg.png this simple flowchart].
 +
*#* Note that these diagram are just examples of how you might build a diagram structurally - the content, or even how you illustrate it, is completely up to you.
 +
*#* It may help to add notes to your diagram to answer below topics.
 +
* When writing or diagraming, try to answer the following:
 +
** What is the progression that the requirements take from inception/idea to issue to specifications to code? How are requirements used in each of the development steps?
 +
** 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 issue to code). How do they all relate / link to each other?
 +
* Finally, reflect on your exploration of this feature and its requirements with 1-2 paragraphs. Did you find that the process was helpful to the developers? Did you find it difficult or easy to follow? What were the ultimate outcomes of the entire process?
 +
 +
 +
 +
=== Deliverables: ===
 +
Students will deliver:
 +
# For Part 1,  their answers to the following questions:
 +
#* Where do requirements fit into the wider software development process? What other processes might requirements feed into?
 +
#* What challenges should you be aware of when utilizing requirements to drive software development?
 +
#* How does requirements-gathering differ in agile-based projects compared to more plan-driven projects (like Waterfall methodology)?
 +
# For Part 2, their answers to the following questions:
 +
#* Why do you think there are so many tools?
 +
#* Give examples of how the separate tools link together to each other on occasion.
 +
# For Part 3, their answers to the following questions:
 +
#* In what tools does the ManageIQ community keep its requirements? Do you find them in multiple places?
 +
#* Recall the [http://talk.manageiq.org/t/how-are-project-mgmt-activities-done-here forum post by ManageIQ's Scrum Master]. What two tools does the central development team seem to rely on the most for tracking requirements and development progress?
 +
#* Where did the git feature start its requirements? Where did they originate from? The development team? A customer? A user? Why do you think this person reported their issue?
 +
#* What does the above question tell you about where communities can get their requirements? Why is it good that requirements are sometimes sourced from outside parties?
 +
#* Why might getting requirements from otherwise uninvolved parties be an advantage for open source communities?
 +
# Their diagram or write-up:
 +
#* See description above
 +
#* Be sure to include a 1-2 paragraph reflection of your experience at the end.
 +
 +
 +
 +
=== Assessment: ===
 
{| border="1" class="wikitable"
 
{| border="1" class="wikitable"
 
! Criteria
 
! Criteria
Line 72: Line 140:
 
|-
 
|-
 
| '''Understanding of requirements in context of wider SDLC'''
 
| '''Understanding of requirements in context of wider SDLC'''
|  
+
| Did not attempt to understand.
|  
+
| Minimum effort in answers to Part 1 (one short sentence for example)
|
+
| Complete understanding, full answers
|
+
| Understanding that shows mastery of how requirements relates to other SDLC steps and methodologies
  
 
|-
 
|-
| '''Explains common methods and tools in oss req. gathering'''
+
| '''Explains common methods and tools in OSS req. gathering'''
|  
+
| Did not attempt to explore tools
|  
+
| Minimum effort in answers to Part 2 (one short sentence for example)
|  
+
| Complete description, full answers
|  
+
| In-depth understanding of requirements gathering tools in open source
  
 
|-
 
|-
 
| '''Can track requirements from initial sources through to code'''
 
| '''Can track requirements from initial sources through to code'''
|  
+
| Did not attempt to track or diagram
|  
+
| Minimum effort to diagram or display an understanding of the example feature
|  
+
| Obvious effort and work put into the diagram or writeup (could be hard to understand or even partially incorrect)
|  
+
| Exceptional diagram and/or writeup, easy to understand, intuitive explanation; possibility of both diagram ''and'' writeup
  
 
|}
 
|}
  
 
=== Comments: ===
 
=== Comments: ===
What should the instructor know before using this activity?
+
* Keep in mind that many of the links to ManageIQ's various tools and resources could change over time. Some may become defunct or outdated. Feel free to update this wiki if you find these, or to inform your students to move-on when they cant find a particular resource - there are plenty of other links and places for them to search around on ManageIQ's resources.
 
+
* The manageIQ community is at least tangentially aware of this activity. As part of creating this exercise, I started a [http://talk.manageiq.org/t/how-are-project-mgmt-activities-done-here How ManageIQ does Project Management forum conversation] to get more information. This conversation is used in the exercise. If you wanted to further the conversation or get more answers, you could always try that forum thread or starting your own in their 'Meta' forum category.
What are some likely difficulties that an instructor may encounter using this activity?
+
* 3-6 hours is a current guesstimate as to how long this will take students to complete. It could be more or less - use your best judgement.
 +
* There is a lot of links and a lot of potential reading. Students should not focus on the technical understanding of the content, and they should not spend excessive amounts of time into any one resource.
  
  
Line 106: Line 175:
 
|'''ACM Topic''' || Requirements tracing; Describing functional requirements; Evaluation and use of requirements specifications;  from https://www.acm.org/education/CS2013-final-report.pdf
 
|'''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
+
|'''Level of Difficulty''' || Medium
 
|-
 
|-
|'''Estimated Time to Completion''' ||  2-3 hrs
+
|'''Estimated Time to Completion''' ||  3-6 hrs
 
|-
 
|-
 
|'''Materials/Environment''' ||  Internet access
 
|'''Materials/Environment''' ||  Internet access
Line 120: Line 189:
  
 
=== Suggestions for Open Source Community: ===
 
=== Suggestions for Open Source Community: ===
Suggestions for an open source community member who is working in conjunction with the instructor.
+
Suggestions for an open source community member who is working in conjunction with the instructor:
 +
* If the scrum master or a product manager or even a developer could talk with a class for 30-60 mins (virtually, over video-chat), this would be a priceless experience for the students.
 +
* Think about how the students might extend this project and actually get involved in the community, noting that they are not going to start with technical details of the issues. Could they summarize the requirements? Improve the existing tool sets or update data in them? Write documentation that points out all of the sources of tools?
  
  
Line 129: Line 200:
 
[[Category: Learning_Activity]]
 
[[Category: Learning_Activity]]
 
[[Category: Specification_and_Design]]
 
[[Category: Specification_and_Design]]
 +
[[Category:Good Draft]]

Revision as of 18:01, 8 March 2017

Title Requirements Analysis (ManageIQ project)
Overview Students will read about software requirements, delve into open source requirements tracking tools in the ManageIQ community (cloud computing), and explain a timeline of how a requirement progressed across the life of a particular feature.
Prerequisite Knowledge Students should 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.
  • (Optional) Cloud-computing, which will help in the ManageIQ example, but teachers could easily use other projects, or tell students to bypass the details of cloud computing for now.
Learning Objectives Upon completion, students should be able to:
  • Understand the requirements-gathering method in context with a wider software development life cycle.
  • Explain what common methods and tools are used in open source requirements gathering.
  • Track requirements, issues, and code from forums, to issue trackers, to code bases.

Background:

Background reading material is given during Part 1 of the exercise.

What is the rationale for this activity?

As software development differs between waterfall and Agile / Iterative development models, it will be important to understand how requirements fit into each model. Open source projects often have a less formal requirements-gathering process than a government contract job, but the requirements are still there in each case. Students should be aware of how requirements are gathered in a distributed diverse community.


Directions:

In this activity, you will dive into a real open source project, and study the numerous requirements-gathering development artifacts around two features of the project. First, you will read some background materials around requirements analysis. Next, you will learn about the ManageIQ project and community. Finally, you will delve into two particular features / issues / code sets in ManageIQ. You will need to illustrate the process, describe a timeline, and answer questions. Technical understanding is not needed; however pay attention to the patterns that the requirements show.

Part 1: Requirements Background

Read the following resources and reflect on the questions below. Note: you only need to read the pages or sections mentioned below, however reading further will prove useful.

  • Requirements analysis overview - Read the "Overview" and "Requirements analysis issues" sections (1 and 4); also review the "Software development process - core activities" table on the right side of the page to understand how requirements fit into the wider Software Development Life Cycle (SDLC). Where do requirements fit into the wider software development process? What other processes might requirements feed into?
  • ACM's quick description - Read the bottom of Page 178 (Page 181 marked by the PDF reader) titled "SE/Requirements Engineering". What challenges should you be aware of when utilizing requirements to drive software development?
  • Atlassians agile requirements tips - Read from the top of the page through the "Keeping requirements lean with a one-page dashboard" section. How does requirements-gathering differ in agile-based projects compared to more plan-driven projects (like Waterfall methodology)?
  • Example of documenting requirements - This is one example of how to write requirements. No need to read it in-depth; simply take a look so that you can see a solid example.

Optional Reading: Requirements in open source - Teachers can decide if they also want to focus on requirements specific to open source. This would be advanced work rather than students simply moving onto the below hands-on sections.


Part 2: ManageIQ intro

In this activity, we will focus on the ManageIQ open source community. ManageIQ is a cloud-enabled management platform (CMP) that lets you: 1) monitor; 2) start/stop; and 3) analyze servers and applications in a corporate cloud infrastructure. For example, if a company decides to make its own set of cloud resources inside their own company, in a big data-room, they may have hundreds of machines to help their employees run servers and web applications. They might use ManageIQ to help keep everything under control and running smoothly. ManageIQ is made in a communal open source fashion. Keep in mind, that before Red Hat acquired them, this community used to be proprietary and closed. They have slowly been moving toward open and communal ways. This is a good ongoing lesson in how to "go open".

ManageIQ development tools

Below is a list of the tools that are used and publicly available for use by the ManageIQ project. Click on each link and observe the various uses for each tool. Why do you think there are so many tools? Give examples of how the separate tools link together to each other on occasion.

  • ManageIQ Github Issues and Creating new Issues
  • ManageIQ Trello / Task board - This is like a complex To-Do list; It is how they track their various requirements/issues; Open and read the upper left box titled "How this board is used: What do these Lists mean????"
  • Forum tool - They call it "Talk" and its where many eventual Features are first introduced and discussed.
  • ManageIQ team - A listing of their team members. Though not directly related to requirements, you will see these team members names and handles across the various tools.
  • How ManageIQ does Project Management - I asked on the talk forum for more information on how they project-manage their requirements and issues. Their [scrum masters (a person who leads a team of agile developers) answer is well worth a read.
  • Sprint Review Meetings (taped on youtube!) - Sprint reviews are cyclical get-together meetings with stakeholders invited to show progress, review feedback, and change directions if needed.
  • Ruby Gem Dependencies - This is a more technical tool used for tracking what other libraries their software depends on


Part 3: Compare two real requirements

Below are two features within the ManageIQ project. Requirements exist inside each features various artifacts (links below). Inspect the links in both and answer the questions below it. After the questions, you will choose one feature to describe, with diagrams and/or words, of what occurred in the progression of the requirement. See more below.

Two requirements examples:

Listed below are two features that the ManageIQ open source project took on and implemented, or are still implementing. Do take note that the git feature started in a forum and progressed to be implemented in chunks by the central ManageIQ developers, who are mostly hired by Red Hat. On the other hand, the chargeback feature was taken up and implemented by a team of community interns. A couple of banks that use ManageIQ combined resources with Red Hat to bring in a handful of student interns to work on this special chargeback feature. They operated separate, but in-sync with the central developers. This is of note, to see similarities and differences in how they tracked requirements and implemented their code.

Read the various links that follow two feature examples.

  1. Git Integration Feature
    • Initial Discussion that started it. Read this in full and dont worry about understanding the technical side of it.
    • They created a Github Issue (bug). Notice how it links from the above discussion.
    • Code that was implemented - Just take a look here, no need to understand it. Again, notice the connection.
    • More code - Again, just peak; Notice how the code links to the Issue.
    • There is even more code, and likely more to come, that will link back to this feature. Take note that this code is implemented across a pretty lengthy time-period.
  2. Chargeback Feature
    • This discussion seems to kick off an initial inquiry; Note the timing and note user "sergio_ocon" who later leads the team of interns to implement this
    • These set of more formal requirements were brought together after the above discussion. Note the many additional pages linked-to off to the right in a small table of contents. Do not worry about the technical descriptions or details - simply get a feel for how they organize the requirements and content.
    • Their github repository actually contains their requirements, specifications, documentation, and code. Note the links to various other resources.
    • This list of bugs are all related to chargeback. This is an example of this student-intern team linking their work back to issues that the central manageIQ project has logged. Open source communities can be separate yet connected.
    • This trello board tracks their development progress. It is separate from the wider ManageIQ communities trello board (linked above).
    • This blog summarizes development milestones made on the various requirements, as well as more human-oriented commentary on the process and politics involved in the resources they used to implement this (student interns hired by customers to work on open source).


Questions

Answer the below questions after having read through the above two examples:

  • In what tools does the ManageIQ community keep its requirements? Do you find them in multiple places?
  • Recall the forum post by ManageIQ's Scrum Master. What two tools does the central development team seem to rely on the most for tracking requirements and development progress?
  • Where did the git feature start its requirements? Where did they originate from? The development team? A customer? A user? Why do you think this person reported their issue?
  • What does the above question tell you about where communities can get their requirements? Why is it good that requirements are sometimes sourced from outside parties?
  • Why might getting requirements from otherwise uninvolved parties be an advantage for open source communities?


Diagram
  • Now, choose one of the examples to document and explain a timeline of how the requirements progressed across the life of the feature.
  • You may choose to:
    1. simply write out the progression (in 3-5 paragraphs), or
    2. to illustrate it with a visual timeline or block diagram such as a flow chart
  • When writing or diagraming, try to answer the following:
    • What is the progression that the requirements take from inception/idea to issue to specifications to code? How are requirements used in each of the development steps?
    • 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 issue to code). How do they all relate / link to each other?
  • Finally, reflect on your exploration of this feature and its requirements with 1-2 paragraphs. Did you find that the process was helpful to the developers? Did you find it difficult or easy to follow? What were the ultimate outcomes of the entire process?


Deliverables:

Students will deliver:

  1. For Part 1, their answers to the following questions:
    • Where do requirements fit into the wider software development process? What other processes might requirements feed into?
    • What challenges should you be aware of when utilizing requirements to drive software development?
    • How does requirements-gathering differ in agile-based projects compared to more plan-driven projects (like Waterfall methodology)?
  2. For Part 2, their answers to the following questions:
    • Why do you think there are so many tools?
    • Give examples of how the separate tools link together to each other on occasion.
  3. For Part 3, their answers to the following questions:
    • In what tools does the ManageIQ community keep its requirements? Do you find them in multiple places?
    • Recall the forum post by ManageIQ's Scrum Master. What two tools does the central development team seem to rely on the most for tracking requirements and development progress?
    • Where did the git feature start its requirements? Where did they originate from? The development team? A customer? A user? Why do you think this person reported their issue?
    • What does the above question tell you about where communities can get their requirements? Why is it good that requirements are sometimes sourced from outside parties?
    • Why might getting requirements from otherwise uninvolved parties be an advantage for open source communities?
  4. Their diagram or write-up:
    • See description above
    • Be sure to include a 1-2 paragraph reflection of your experience at the end.


Assessment:

Criteria Level 1 (fail) Level 2 (pass) Level 3 (good) Level 4 (exceptional)
Understanding of requirements in context of wider SDLC Did not attempt to understand. Minimum effort in answers to Part 1 (one short sentence for example) Complete understanding, full answers Understanding that shows mastery of how requirements relates to other SDLC steps and methodologies
Explains common methods and tools in OSS req. gathering Did not attempt to explore tools Minimum effort in answers to Part 2 (one short sentence for example) Complete description, full answers In-depth understanding of requirements gathering tools in open source
Can track requirements from initial sources through to code Did not attempt to track or diagram Minimum effort to diagram or display an understanding of the example feature Obvious effort and work put into the diagram or writeup (could be hard to understand or even partially incorrect) Exceptional diagram and/or writeup, easy to understand, intuitive explanation; possibility of both diagram and writeup

Comments:

  • Keep in mind that many of the links to ManageIQ's various tools and resources could change over time. Some may become defunct or outdated. Feel free to update this wiki if you find these, or to inform your students to move-on when they cant find a particular resource - there are plenty of other links and places for them to search around on ManageIQ's resources.
  • The manageIQ community is at least tangentially aware of this activity. As part of creating this exercise, I started a How ManageIQ does Project Management forum conversation to get more information. This conversation is used in the exercise. If you wanted to further the conversation or get more answers, you could always try that forum thread or starting your own in their 'Meta' forum category.
  • 3-6 hours is a current guesstimate as to how long this will take students to complete. It could be more or less - use your best judgement.
  • There is a lot of links and a lot of potential reading. Students should not focus on the technical understanding of the content, and they should not spend excessive amounts of time into any one resource.


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 Medium
Estimated Time to Completion 3-6 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:

  • If the scrum master or a product manager or even a developer could talk with a class for 30-60 mins (virtually, over video-chat), this would be a priceless experience for the students.
  • Think about how the students might extend this project and actually get involved in the community, noting that they are not going to start with technical details of the issues. Could they summarize the requirements? Improve the existing tool sets or update data in them? Write documentation that points out all of the sources of tools?



This work is licensed under a Creative Commons Attribution 4.0 International License

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox