Gathering requirements for a Non-technological project
Denis_Parra
As part of a project in a graduate course of System Analysis, the
professor has defined a final project for all the class which consists
in gathering the requirements for the creation of a new Academic
Program for the College of General Studies on our University. The
professor has divided the whole project in 5 areas, each one is
addressed by a correspondent group. In my case, my group is gathering
requirements for the area "Student Affairs"
Since the "product" of the Requirements Elicitation is an academic
certificate program, in some situations I feel confused about the
classification of the requirements. The University has an ERP software
to manage the enrollment process, billing, academic issues, etc, but
this is just a technological element (an interface) involved in the
project. For instance, the following requirement:
"The students shall be able to enroll in any term (Spring, Fall or
Summer)"
how can I classify it?
1. Clearly is not a project driver
2. If I see the project as the "creation of a new academic program"
and the product as the program itself, this is not a Project
Constraint. A project constraint would be "the program must be
approved by the Provost of the office XXX"
3. If I see the enrollment as a functionality of the "product", the
requirement described seems to be more a design constraint or a non-
functional constraint
Any suggestions? Thanks in advance. Regards,
--Denis
James Robertson
On 8 Oct 2008, at 01:39, Denis_Parra wrote:
>
> Hi,
>
> As part of a project in a graduate course of System Analysis, the
> professor has defined a final project for all the class which consists
> in gathering the requirements for the creation of a new Academic
> Program for the College of General Studies on our University. The
> professor has divided the whole project in 5 areas, each one is
> addressed by a correspondent group. In my case, my group is gathering
> requirements for the area "Student Affairs"
You have to be very clear on the goal of the project. Does the
professor want the requirements for "the creation of a new academic
program", or the requirements for "an academic program"? It seems a
small difference but it is significant.
> Since the "product" of the Requirements Elicitation is an academic
> certificate program, in some situations I feel confused about the
> classification of the requirements.
The same question as above. Is it really the program that is to be the
product in this case?
I will assume that it is for the rest of my answer.
> The University has an ERP software
> to manage the enrollment process, billing, academic issues, etc, but
> this is just a technological element (an interface) involved in the
> project. For instance, the following requirement:
>
> "The students shall be able to enroll in any term (Spring, Fall or
> Summer)"
This is a requirement for the product regardless of whether it is
eventually implemented using ERP software, manually or any other means.
> how can I classify it?
>
> 1. Clearly is not a project driver
Nope, it is just a functional requirement that the product has to
carry out. That is, it is something that the product has to do to
support the business.
> 2. If I see the project as the "creation of a new academic program"
> and the product as the program itself, this is not a Project
> Constraint. A project constraint would be "the program must be
> approved by the Provost of the office XXX"
Not necessarily. Constraints are hard to categorise, as most of them
look like regular requirements. I would not be too concerned about the
category. The Provost's approval is just another part of the product.
> 3. If I see the enrollment as a functionality of the "product", the
> requirement described seems to be more a design constraint or a non-
> functional constraint
I think it is simply a functional requirement. It does hwoever need a
little clarification. Does it mean that the student can enroll in the
term of his/her choice but can only do so at the appropriate time?
That is, the product shall enroll the student for the current term. Or
does it mean that the product shall enroll the student in the selected
term, and shall do so at any time of the year. And can the student
enroll in only one term, or one term at a time?
In any event, the enrollment is part of what the product has to do,
and is thus a functional requirement.
> Any suggestions? Thanks in advance. Regards,
As a suggestion, I would clarify what the product is, and define the
boundaries of the business area to be studied. For example, an
academic program has lots of connections to the rest of the
university, and will overlap with some functionality that would at the
moment be thought of as belonging to another part of the U. I would
try and be as clear as possible about what you are studying.
It might help if you think of all of "student affairs" (this is
nothing to do with romance is it?) as being either completely manual,
or completely automated. For the latter, disregard computers and what
they can do. Instead imagine that you have a number of perfect robots
capable of perfect thought and perfect memory. I say this because you
are looking at a piece of business where there is probably some
automation and some manual processes. It helps if you disregard the
difference between them.
Good luck with the project.
James
>
>
> --Denis
>
>
>
> >
Denis_Parra
I think the product is in fact the program itself. One of the
objectives of gathering the requirements is following the
specification as a template to take into account when creating a new
program.
Respecting Student Affairs, this has no relation with romance :P, it
actually refers to the advising process of the students, enrollment,
transferring credits if the student comes from a community college,
etc.
Thanks for your advice and answers. Regards,
--Denis