Requirements Analysis

(Difference between revisions)
Jump to: navigation, search
(Added links and questions to Part1; Made a questions section; Spiffed up the ManageIQ section Part2)
(moved questions in part2; summarized links in part2;)
Line 36: Line 36:
 
* [https://confluence.atlassian.com/doc/blog/2015/08/how-to-document-product-requirements-in-confluence Skim this] so you can quickly see one example of how to write requirements.
 
* [https://confluence.atlassian.com/doc/blog/2015/08/how-to-document-product-requirements-in-confluence Skim this] so you can quickly see one example of how to write requirements.
  
Optional: Requirements in open source - Teachers can decide if they want to focus on requirements specific to open source. This would be advanced work versus, students simply moving on into the below hands-on sections.
+
Optional: Requirements in open source - Teachers can decide if they also want to focus on requirements specific to open source. This would be advanced work versus students simply moving on into the below hands-on sections.
  
 
* [http://news.slashdot.org/story/00/10/23/1250228/gathering-requirements-in-open-source-projects Does open source have requirements?] - Of special interest is the comments by "FortKnox" and "ivan256" where each of them gives differing views on waterfall vs an iterative approach to requirements management
 
* [http://news.slashdot.org/story/00/10/23/1250228/gathering-requirements-in-open-source-projects Does open source have requirements?] - Of special interest is the comments by "FortKnox" and "ivan256" where each of them gives differing views on waterfall vs an iterative approach to requirements management
Line 47: Line 47:
 
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 monitor, start/stop, and analyze servers & applications in a corporate cloud infrastructure. So, for example, a company decides to make its own set of cloud resources inside their own company, in a big data-room. They have hundreds of machines helping their employees to run servers and web applications. They might use ManageIQ to help keep it all under control and running smoothly. ManageIQ is made in a communal open source fashion. Keep in mind, that this community ''used'' to be proprietary and closed - when Red Hat acquired them, they have slowly been moving toward open and communal ways. It is a good ongoing lesson in how to "go open".
 
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 monitor, start/stop, and analyze servers & applications in a corporate cloud infrastructure. So, for example, a company decides to make its own set of cloud resources inside their own company, in a big data-room. They have hundreds of machines helping their employees to run servers and web applications. They might use ManageIQ to help keep it all under control and running smoothly. ManageIQ is made in a communal open source fashion. Keep in mind, that this community ''used'' to be proprietary and closed - when Red Hat acquired them, they have slowly been moving toward open and communal ways. It is a good ongoing lesson in how to "go open".
  
==== ManageIQ Dev Tools ====
+
===== ManageIQ development tools =====
Below is 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.
+
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????"
+
* ManageIQ [https://github.com/ManageIQ/manageiq/issues/ Github Issues] and [http://manageiq.org/community/issues/ Creating new Issues]
* [http://talk.manageiq.org/ Forum tool] - They call it "Talk" and its where many eventual Features are first introduced and discussed
+
* 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????"
* ManageIQ [http://manageiq.org/community/team/ team] - A listing of their team(if I want to mention it in passing - just a neat resource to show)
+
* [http://talk.manageiq.org/ Forum tool] - They call it "Talk" and its where many eventual Features are first introduced and discussed.
* Forum question/answer around [http://talk.manageiq.org/t/how-are-project-mgmt-activities-done-here how ManageIQ does Project Management]
+
* 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.
* [https://www.youtube.com/playlist?list=PLQAAGwo9CYO-SEH9SW7IEwDF6-IzlB_mx Sprint Review Meetings (taped on youtube!)]
+
* [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 scrum masters answer is well worth a read.
* [https://gemnasium.com/ManageIQ/manageiq Ruby Gem Dependencies]
+
* [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
Answer 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.
+
  
  
  
 
==== Part 3: Compare two real requirements ====
 
==== Part 3: Compare two real requirements ====
* Have students explain how requirements are held and managed in both traditional waterfall SDLC methods and agile / iterative SDLC methods
+
Below are two features within the ManageIQ project. Requirements exist inside each features various artifacts. Inspect the links in both and answer the below questions.
* Now, show students the two requirements / features / issue tracker. Give context so that they know was community and one was an offshoot team
+
Next, choose one feature to Illustrate a timeline, with pictures and/or words, of what occurred in the progression of the requirement. See more below.
  
 
* Have students document and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project
 
* 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 question/answer sheet that they must fill out (make a simple PDF)
 
 
** Where did the requirement start its life? What did it look like? Who reported it?
 
** 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)
 
** Repeat this for each major step of the life (talk forum to github issue to code)
Line 75: Line 71:
  
  
==== Two requirements examples: ====
+
===== Two requirements examples: =====
Listed below are two features that the ManageIQ open source project took on and implemented (or are still implementing).  
+
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 hired community interns. A couple of banks 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.
 
Read the various links that follow two feature examples.
  
** Git Integration Feature  
+
# Git Integration Feature
*** [http://talk.manageiq.org/t/version-control-integration/414 Initial Discussion],
+
#* [http://talk.manageiq.org/t/version-control-integration/414 Initial Discussion]
*** [https://github.com/ManageIQ/manageiq/issues/1199 They created a Github Issue (bug)],
+
#* [https://github.com/ManageIQ/manageiq/issues/1199 They created a Github Issue (bug)]
*** [https://github.com/ManageIQ/manageiq/pull/1204 Code that was implemented] - Just take a look here, no need to understand it
+
#* [https://github.com/ManageIQ/manageiq/pull/1204 Code that was implemented] - Just take a look here, no need to understand it
*** [https://github.com/mkanoor/manageiq/commit/9c889c0269f25e3823dbae2b93b1120ea3e70538 More code] - Again, just peak; Notice how the code links to the Issue
+
#* [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 more to come, that will link back to this Feature. Take note that this code is implemented across a pretty lengthy time-period
+
#* 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
** Chargeback Feature
+
#* [http://talk.manageiq.org/t/chargeback-open-discussion/440/10 discussion]
***[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?]  
+
#* [https://github.com/rhus/charging-docs/wiki/Requirements:-Collection-and-Mediation requirements]
 +
#* [https://bugzilla.redhat.com/show_bug.cgi?id=1052106 bug?]
  
 +
http://xmindshare.s3.amazonaws.com/preview/requirements-timeline-lysaa-1255969706300.jpg
 +
http://boxesandarrows.com/files/banda/case-study-of-agile/devotimeline.jpg
 +
https://upload.wikimedia.org/wikipedia/commons/thumb/9/91/LampFlowchart.svg/2000px-LampFlowchart.svg.png
  
 
=== Deliverables: ===
 
=== Deliverables: ===

Revision as of 04:18, 30 January 2016

Title Requirements Analysis
Overview Students will read about software requirements, dig into a particular open source communities requirements tracking tools, 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) Having a knowledge of cloud-computing will help in the ManageIQ example, but teachers could easily use other projects, or tell students to ignore the details of cloud computing for now.
Learning Objectives Upon completion, students should:
  • understand what requirements gathering means 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.
  • be able to track requirements, issues, and code from forums, to issue trackers, and through code bases.

Background:

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

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.


Directions:

In this activity you will dive into a real open source project, and study numerous requirements gathering development artifacts around two features of the project. First, you read some background material 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, illustrating the process, describing a timeline, and answering questions.

Part 1: Requirements Background

Read the following resources and reflect on a few questions. Note that you only need to read the pages or sections mentioned.

  • Requirements analysis overview - Read the "Overview" and "Requirements analysis issues" sections; Understand how requirements fit into the wider "Software development process - core activities" in the table on the right. 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). 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 to the "Keeping requirements lean with a one-page dashboard" section. How do requirements gathering differ in agile-based projects compared to more plan-driven projects (like Waterfall methodology)?
  • Skim this so you can quickly see one example of how to write requirements.

Optional: Requirements in open source - Teachers can decide if they also want to focus on requirements specific to open source. This would be advanced work versus students simply moving on into 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 monitor, start/stop, and analyze servers & applications in a corporate cloud infrastructure. So, for example, a company decides to make its own set of cloud resources inside their own company, in a big data-room. They have hundreds of machines helping their employees to run servers and web applications. They might use ManageIQ to help keep it all under control and running smoothly. ManageIQ is made in a communal open source fashion. Keep in mind, that this community used to be proprietary and closed - when Red Hat acquired them, they have slowly been moving toward open and communal ways. It 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 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. Inspect the links in both and answer the below questions. Next, choose one feature to Illustrate a timeline, with pictures and/or words, of what occurred in the progression of the requirement. See more below.

  • Have students document and explain a timeline of how a requirement progressed across the life of a particular feature within an OSS project
    • 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?


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 hired community interns. A couple of banks 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
  2. Chargeback Feature

http://xmindshare.s3.amazonaws.com/preview/requirements-timeline-lysaa-1255969706300.jpg http://boxesandarrows.com/files/banda/case-study-of-agile/devotimeline.jpg https://upload.wikimedia.org/wikipedia/commons/thumb/9/91/LampFlowchart.svg/2000px-LampFlowchart.svg.png

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 do requirements gathering differ in agile-based projects compared to more plan-driven projects (like Waterfall methodology)?
  1. 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.
  1. For Part 3, their answers to the following questions:
    • FIXME


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

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