You have to write 5 functional requirements each for any two of the departments (out of four) of your choice, that must be fulfilled during the software development. [5+5 marks]

There are four main activities in the requirements engineering process:

1. Feasibility study:
   An estimate is made of whether the identified user needs may besatisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more The requirements engineering process
   detailed analysis (feasibility report).
2. Requirements elicitation and analysis:
   This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and buyer, task analysis. This may involve the development of one or more system models and prototypes. These help the system developer understand the system to be specified.
3. Requirements specification:
   Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; System requirements are a more detailed description of the functionality to be provided.
4. Requirements validation:
   This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.Of course, the activities in the requirements process are not simply carried out in a strict sequence. Requirements analysis continues during definition and specification and new requirements come to light throughout the process. Therefore, the activities of analysis, definition, and specification are interleaved. In agile methods,such as Extreme Programming, requirements are developed incrementally according to user priorities and the elicitation of requirements comes from users who are part of the development team.

1. Software license costs of the product
2. Renewal costs over period of contract
3. Support and maintenance contract costs
4. License costs of associated products, e.g. database license, digital certificate costs, etc.
5. Project management costs
6. Implementation costs
7. Escrow costs (if using)
8. Consultancy and advise (if using)
9. End user training

1. Research of requirements
2. Project management costs
3. Cost of specialist design team and business analysis consultants
4. Costs of internal development team
5. Costs of outsourcing, if using
6. License costs for hardware and software development tools
7. License costs for associated software such as databases, digital certificates, etc.
8. Costs in time to market
9. Test support costs, including UX /accessibility testing, setting up and costs of test servers
10. Technical authors for user guides and other documentation
11. End user training
12. Environment costs
13. Code analysis costs (if performing)
14. Maintenance and new feature deployment (post production)

Being a Project Manager, you have to take the decision for “Buy or Build”. Will you buy the Software from any renowned Software house or Developed your own EMS System? You have to Justify with solid reasons in any case. [5 marks]

Part 1: Traditional reasons for buying
In my experience the case for buying software is often not made on the back of arguments that show why buying is a good idea. The usual route seems to be to analyse why building is a bad idea. This in itself says something. It is as if building is the natural answer and only problems with it make it necessary to take a different approach. So, what are these problems that have led people to preferring to buy a package?

Software development is risky
Software development is inefficient
Software development is not our core competency

[1] Mitchell Bingemann, “Dealers still fuming at ‘clumsy’ Telstra system”. The Australian, 2 June 2009.

[2] Tom DeMarco, “Software Engineering: An Idea Whose Time Has Come and Gone?” IEEE Software, July/August 2009.