assignment

[guru prasanth]

In the part2 assignments should i just stick to the requirements they had given me.For the system to goto production there are many other workflows that are required than what they had given in requirement.
Can i make those out of scope but mention that.Or i need to implement as part of design.

[Fernando Franzini]

Hi Guru

Think with me ... you are being hired to design a solution and not put it into production. Designing a solution is to make high level decisions ... of course we all know that practicing things happen a bit different. Given this perspective, make your decision whether you should or should not go into such detail.
Best Regards.

[guru prasanth]

Hi,
Thanks for your reply.For example every web application will have a login module.It's not part of requirement.
But in realtime requirement gathering we will usually account for login module as well.If i include login then
authentication comes into picture and then security tokens.It keeps going on & on.So if i keep doing it the assignment becomes
very big and might be deviating too much from the orginal issue.It's generally said assigmnment should take 40 hours.But in this case
it will take 80 hours.

[K. Tsang]

Sticking to the requirements is key. Deviating too much will probably loose points. If you believe a module (not in requirement) should be included then just mention it in the docs but don't design it (draw UML diagrams).

Remember it's high level design not implementation.

[Fernando Franzini]

guru prasanth wrote:Hi,
Thanks for your reply.For example every web application will have a login module.It's not part of requirement.
But in realtime requirement gathering we will usually account for login module as well.If i include login then
authentication comes into picture and then security tokens.It keeps going on & on.So if i keep doing it the assignment becomes
very big and might be deviating too much from the orginal issue.It's generally said assigmnment should take 40 hours.But in this case
it will take 80 hours.

Make Assumptions

The path of assumptions, you have two ways to go:

- Suppose something already exists in the proposed solution and thus do not do anything related to it and document this assumption.
- Suppose that something does not exist in the proposed solution and thus need to be considered when adding and architecture as part of their proposed solution. Beware that way, since you will be increasing your project and therefore opening more spaces for inconsistencies and errors.

My tip for this is: do not assume or invent things that add complexity to your project. Make assumptions of things that are missing in order to complement the possible lack of information. Resist the temptation to do fancy stuff.

See - http://fernandofranzini.wordpress.com/2013/05/03/my-tips-on-ocmjea/