ConstraintsIn the initial planning phase of the project, limitations were identified that had to be factored into. Constraints that we have identified are as follows:The deadline to submit the project is 11th December 2017, so the project must be finished and working before that date. Managing a larger group might be quite constrain what skills can be used within this project as certain peoples skills might overlap making them redundant resulting in wasted production. The project must be coded in C# on Visual Studio. The user interface must be done through WPF once again through Visual Studio. The finished program should be able to run on University computers. The only permitted libraries are the standard .NET components and assemblies. For storage you are only permitted to use SQLite library, and libraries for manipulating XML and JSON documents. The program should be created with Object Oriented principles in mind. The program code should be modular to allow high cohesion and low coupling. Third party libraries and code are not allowed even if they are open source. The project is limited to being completed only by the group and no outside parties. The user interface must be user friendly and easily accessible for people with no knowledge of the system. The deliverables should be submitted through the SVN trunk provided to the group. You are permitted to implement additional features, however it is not necessary and should not affect the outlined functionality.AssumptionsIn the original specification provided by the theatre company they aimed to make it clear just how they expect the program to work and what it’s required inputs and outputs should be in order to ensure that it works as intended.The problem that arises from this is that while the specified aimed to cover the required content it did not provide enough information about specific details.What this results in is the developers of the software having to assume that something that may not be true to be true due to the simple lack of adequate information provided by the client upfront. This is a common process in a any software development project but in order to ensure that the developers of the software have a clear outline of just what the software they are developing is it is important to look at the what-if situations and to explain the logic behind including and excluding parts/features of the software and in this section of the report that is exactly what will be done. To simplify the software that is being developed it front and foremost a seat booking system that is to be used by a theatre to manage its customers reservations of seats.Which is why when the theatre provided the specification for the the software they included an image showing the layout of the theatre as shown below. The theatre company provided us with this birds eye view of its seating arrangements with the intent to make it clear the layout of the seats that the software that our group will be developing to manage.The biggest assumption that we as a group have to assume in relation to the seating arrangement is that this will be the currently in use seating arrangement when the software has been developed.This may seem obvious but there is no evidence provided by the theatre company to confirm that this is the currently in use seating arrangements and will not change in the foreseeable future.This could simply be a example but with no evidence to say it is a example to show a suitable layout for the seat viewing or the actual in use layout of the theatre that the software should adhere to.When writing up requirements for a software project as large and as complex as the one that this group is undertaking it is clear that even very minor things need to be clearly addressed with the whole group to ensure that everyone is on the same page. With the project we have to assume that this is the layout of the theatre and this is the seating arrangement that should be used in the software that is being developed but this still leaves other assumptions about the seating management.Another topic that was brought up and discussed when it came to writing the requirements for the software was should their paying customers allowed to stand whilst watching a watch a play.This issue arose during the initial planning of the requirements as a member of the group asked what would happen if a customer booked six seats but there was only five seats left for that play.This then means that we have to assume one of two possibilities would happen the first being that the customer’s booking could go through and they would reserve five seats while a the sixth booking would have to sit in the rows potentially being a health and safety risk.The other possibility is that the software simply shall not allow a user to book six seats if there is only five seats left and limit the booking to those five seats and inform the user that they simply cannot book six seats when only five are available. In this situation we have to assume that the second outcome is the correct and desired method that should be implemented into the software as it is the most logical solution whilst at the same time ensuring that every customer does in fact get the seats that they pay for. These situations are just a few examples of the planning that needs to go in the requirements development in order to ensure that the software that is developed is developed with a defined outcome that should be achieved through its requirements .In order to ensure that the program does meet the required functionality as specified by the theatre is important that when comes to writing up the requirements that we as the software developers discuss these “what-if” solutions to ensure that all clear as a group just how we intend to implement the required functionality and how certain situations in relation to situations that can arise during typical use of the software should be resolved and what features should be implemented into the software to ensure that other outcome of these “what-if” situations do not need to be used and the user of the software does not have to deal with possible issues.