CSSE 571
Fall, 2014
Notes for class 4
Tuesday, Oct 7
I.
II.
III.
IV.
What was due yesterday - Paper part 3 - Analysis
a. If you still need for me to grade this or anything else, please let me know by email!
Let's talk about your projects-a. The analysis assignment
b. How you've done now as "research" in this area - getting the actual data!
i. Material sources
ii. People sources
Modeling requirements for something - let's try it!
a. The project - See "Tonight's special project - something to model" - after this discussion
outline.
b. Our goals will be to create:
i. A business model - why it's needed
ii. A feature model - what features are needed to support that
iii. A requirements analysis model - defining use cases, etc. -- the actual product
specs that would lead to a design model as the next step
What's in Berenbach, Ch 4, about MDRE - Model-Driven Requirements Engineering?
a. An attempt to create a unified model to support product development
i. Berenbach's modeling approach reflects his organization (p 79):
1. Telecom customers a. Big projects
i. Often same ones for different customers, or
ii. Upgrades from prior products Seimens also did
b. Many requirements can be predicted
i. Thus, his ability to use forms to ask for requirements,
and
ii. Automate some parts of the resulting design.
2. This probably applies to "custom job shop work" like Siemens does.
a. But the way they do each part of the model is interesting!
ii. Issues with different kinds of artifacts (pp 82-4)
1. How to trace interacting parts?
2. How is completeness determined? (See pp 113+)
iii. Other issues (pp 87+)
1. Introducing YAT (Yet another tool)
a. Nobody knows it!
b. What does it talk to?
c. What does it force you to change in your processes?
2. Organization isn't ready for this much "regimentation"
3. Probably need someone just managing the MDRE system
iv. Advantages of unified approach
1. Ways to compare projects a. Estimate costs based on experience
b. Metrics
c. Better mgmt. of cross-cutting requirements (QA's)
d. Navigation by users
i. What's tied to this requirement?
1. If it goes away, what else goes?
2. What happens when we move to the next
release?
ii. Access to more info by any one developer, etc.
1. Know how features will be used and why
iii. Everyone can see "why we're doing this"
1. Rationale for individual features
e. Semi-automatic generation?
i. This part will, once again, follow Standard X, so…
b. Business modeling
i. Modeling the customer's business
1. Context - Where the new system fits in - what "pain" it will remove
2. Not just a Domain Model (See CSSE 574), but also rationale for why
things need to be done a certain way
ii. Modeling your own organization as well?
1. Part of "how you will do it?"
iii. Use graphical techniques to show relationships
1. These need accompanying explanations!
c. Feature/goal modeling
i. Idea is to go from abstract to concrete use cases
ii. Make a "feature tree" - Example:
iii. Stop when you get to concrete use cases (no additional detailing needed to
capture requirements)
d. Use case modeling
i. Obviously captured in the above feature-modeling process!
ii. Use cases look like these pictures, as graphic alternatives to text:
iii. End result can be one of these -1. A requirements database from the data in the model
2. A table of requirements
3. An "SRS" (Systems Requirement Spec or Software Requirements Spec)
e. Design modeling (pp 115+)
i. Usually look at use cases, pulling "objects" from them, and separately deciding
on what classes and other key entities will be in the system.
ii. Resulting software design may or may not look like the use case design.
1. Use cases often are a close guide for creating classes, but not
necessarily!
iii. Ways that the requirements model and design model can interact (yikes!):
f.
Implementation modeling
i. This is generating the code from the design.
ii. The code is the model.
g. What do you actually do in creating a requirements model?
h. Important to do "model reviews" to get a common understanding of completeness, etc.
i. Can use heuristics to judge the model, pp 99+
i. Single entry point?
1. Often a "context diagram"
ii. Covers breadth of the domain?
iii. Any "out of scope" use cases?
iv. Quality of the diagrams 1. Associated description
2. Status
v. "Packages" can be deadly
1. Not the same as abstract use cases
vi. Is every artifact visible?
vii. Bi-directional hyperlinks?
1. Knowing "what references this?" - usually tougher to know
viii. Package dependencies based on context?
ix. Every concrete use case defined?
x. Example of a "high quality" activity diagram version of a use case:
V.
xi. Is every abstract use case realized down to concrete level?
xii. Is every business process represented in use cases?
xiii. Define the "boundaries" through which actors interact in the use cases (see p
111)
xiv. Use the model to elicit additional requirements
j. What's "model completeness" mean? (pp 113-4, especially Table 4.2)
i. Diagram quality
ii. Content correctness
iii. Model faults
What's next? - see schedule and assignments
A. Next class - Tuesday, Oct 14, 5:00 PM, here
i. Topics will be
1. Non-functional requirements - Ch 5 in Berenbach, etc.
2. Interaction Design - First half of the IA Design book! (Skim)
B. Take-home exam 1 - Will be available next class, due a week later, Oct 20? (proposed)
Tonight's special project - something to model:
The goal is to come up with a model of the use cases, like Berenbach Ch 4 recommends.
A Graduation Planning System for Rose-Hulman
[Same system that is the official example of use cases & other requirements, on the course web site.]
Need statement
Undergraduate students are arguably the major customer of Rose-Hulman. (With the other option being that it's
really their parents.) What these students are trying to achieve is graduation, on their way to a good job or graduate
school. Reducing the hassle and uncertainty of their progress would be a major satisfier for them.
Most Rose-Hulman undergraduate students need to try to plan how they'll reach graduation, for a program that's
typically over 4 years. As incoming freshmen, they may not even be sure what their major will be, so they very
often change that initial declaration of major. In addition, they make refinements such as declaring a second major,
or a minor, or an area of concentration. All these decisions interact, and such interactions can impact the student's
ability to achieve what they think they are going to be able to do. This complexity creates the hassle and uncertainty
for them, at present.
A Graduation Planning System would help to simplify this process, enabling students, with greater assurance, to
plan their future coursework with the desired outcomes. For example, it could flag, "If you don't take this course
now, you won't graduate in 4 years without overloading."
Such a system also would benefit advisers, department heads, and the registrar, all of whom are involved in planning
courses and when students take those courses. All could see, for example, the impacts of changes made to curricula,
to when students take courses, or to how they are offered (like scheduling conflicts impacting students).
Scope
The Graduation Planning System will allow current students and advisors to plan a course of study for any RoseHulman major and minor. The system will be designed to show which classes must be taken during which quarter
to graduate at a specific time. Additionally, changes of majors and minors will be allowed and the system will show
what impact these changes will have on the graduation date. The system will be integrated with the existing RoseHulman Banner Web to allow students to register for online for the classes they have chosen. (Banner is the school
business & accounting system, which also has info about classes students already have taken, etc.)
Not included in the scope of this project are:












The application will not perform and scheduling functions. [stet]
Graduation planning for Master level students.
Perspective Rose Students will not be able to view a course of study.
Tools for advisors
Tools for registrar (student interest level, alert for scheduling conflicts)
Reporting by quarter, year, student status, major, professor, class size, class room
Integration with financial aid office.
Ability to recognize courses that don't count for overloading (ROTC, life skills)
Ability to be used as a forecasting tool for department heads in order to predict the number of sections
required.
Ability to create ad-hoc reports.
Ability to see final test schedules.
Handling online web based courses.
Typical scenarios for the major users -
1.
A student sits at a screen and views their current courses - those taken and those planned to take. They then do
"what if" changes to that schedule, which could take different forms, such as:
1.1 "What if I want to graduate one term earlier? Can I do it? Will I have to take an overload more
times?"
1.2 "What if I also want to major in math? Can I still graduate in 4 years?"
1.3 "What if I wait till my last term to take DE-2? Will that mess-up anything?"
2.
A student sits at a screen and says, "Please pre-register me for the classes shown."
3.
The registrar looks at a report of pre-registrations that shows what classes students are expecting to take, to
pursue their graduation plans.
4.
An advisor reviews the graduation plans of his/her advisees, with or without them being present.
5.
A department head inputs the graduation requirements for a particular program, initially or as changes. The
system will show any impacts of changes on individual students in that program.
6.
A department head makes "impacting changes" to a course description, such as its prerequisites, or which terms
it is expected to be offered.
Function
[Section taken from the Problem Statement for this system]
Key Business Features
[Based on discussions with the team's client, who is a professor advocating this system]
Feature No.
1
2
6
7
8
9
10
11
14
15
16
17
18
19
20
21
23
25
27
Feature Name
Ability to generate suggested courses (from lists of those offered) and setup a graduation
timeline.
Ability for a department head to add new courses or remove old courses, with related info
like their prerequisites and when they typically are offered.
Ability to generate different freshman schedules based on possible majors.
Ability to recognize fast-track credits. (For a Rose summer math program.)
Allow quarters to be skipped, showing impacts. (See also # 32, below.)
Allow part time, full time and course overload.
Auto link to preview course descriptions and prerequisites.
Department head has access to modify course offerings, need of prerequisites and class
size.
Ability to have double majors
Ability to enter advanced-placement credits
Ability to enter off-campus credits
Access to grade replacement for failing grades to indicate that a course has been passed.
Ability to recognize transfer credits.
Ability to substitute a class (E.g. substitutions often are "approved" to count for something)
Ability to recognize major/minor change (real changes, or "what if" changes).
Ability to recognize dropped or added courses.
Course information and prerequisite information available for viewing.
Ability for dept. head to add a new major or minor.
Ability to ‘preview” what-if majors and minors
28
30
31
32
33
34
35
52
53
54
56
57
58
59
60
Graphical representation (arguably a quality attribute)
Ability to save a what-if scenario
Ability to identify course sequences for all majors including prerequisites.
Ability to allow for co-op or sitting out a quarter.
Ability for dept. head to drop an old major or minor.
Ability to take prerequisites at the same time as course.
Ability to assign another advisor
Ability to view course name on the schedule grid when the mouse is moved over the course
number.
Ability for changes in the schedule to ripple throughout the graduation plan as they are
applied as constraints.
Visual Queues: Show which courses have been taken: area, fee, tech, or restricted elective.
Allow for “fixing” a quarter so that the ripple affect will not change the specific quarter.
Use drop down boxes for area, tech and restricted elective. (A Design Constraint)
Split Free Elective Selection into a separate screen showing course prefix and course
number. (A Design Constraint)
Allow generic class prefix and number selection as placeholders for humanities and tech
electives. (A part of usability)
Ability to add constraints to schedule via buttons on the main schedule screen. (A Design
constraint)
Key enabling features
Feature No.
4
5
22
Feature Name
Compatible with existing software.
Compatible with existing hardware.
Access to system with knowledge of which courses have been completed successfully.
Key interfaces
Feature No
3
Feature Name
Integration with Banner (the school business & accounting system, which also has info
about classes students already have taken, etc.).