It seems to me that you don't want to try to break this data into several subtype tables, as you will end up with a lot of unwanted complexity. Also, if you later decide that e.g. attribute MHRS DOES apply to project type EA after all (business rule change), you will have to rework your design. Ditto if a 9th project type comes along that has yet another combination of valid attributes.
You can accomplish this with 1 table that has all the possible attributes, and check constraints to enforce the various business rules, for example:
ALTER TABLE project
ADD CONSTRAINT project_chk1
CHECK ((project_type IN ('ED', 'EO', 'ESR') AND speciality IS NOT NULL) OR (project_type NOT IN ('ED', 'EO', 'ESR') AND speciality IS NULL));
Now any new project types or modifications to existing project types will not impact your table design, just the constraint text.